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ABSTRACT 


A  model  is  developed  to  simulate  various  aspects  of  Naval 
Supply  Center  requisition  processing.  The  model  is  based  on 
the  Q-GERT  simulation  language.  Q-GERT  was  selected  because 
of  the  likelihood  that  existing  stock  point  personnel  could 
be  easily  trained  to  model  stock  point  requisition  throughput 
with  a  language  that  is  coded  directly  from  a  visual  display 
of  the  processes  being  simulated.  This  thesis  introduces  the 
basic  Q-GERT  concepts  and  develops  the  necessary  symbology 
to  model  the  NSC  San  Diego  NSN  requisition  throughput  procedure. 
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I.  INTRODUCTION 

There  are  many  advantages  associated  with  the  maintenance 
of  a  capability  to  simulate  both  current  and  proposed  operating 
procedures  in  a  variety  of  settings.  Models  have  been  developed 
to  assist  in  the  decision  making  process  in  such  diverse  areas 
as  traffic  control,  war  games,  and  for  our  specific  purposes, 
requisition  processing.  Models  (simulators)  that  closely 
approximate  an  existing  operating  system  can  be  used  confidently 
to  predict  the  consequences  of  procedural  changes.  Models 
characterized  by  variables  that  have  been  shown  to  possess 
particular  distributional  qualities  may  have  a  quantifiable 
predictive  value;  i.e.,  a  numeric  level  of  confidence,  or  degree 
of  certainty,  in  the  predictions  obtained  can  be  calculated. 

At  the  very  least,  any  reasonably  representative  model  can  be 
used  to  assess  the  relative  impact  of  various  procedural  changes 
each  proposed  alternative  is  being  subjected  to  identical  model 
assumptions  and  the  degree  to  which  these  assumptions  may 
invalidate  simulation  output  can  be  estimated  across  the  con¬ 
templated  alternatives.  Most  importantly,  a  realistic  simulator 
permits  an  informed  analysis  of  procedural  changes  without 
incurring  the  costs  that  would  accrue  if  the  system  itself  were 
actually  modified. 

A  simulation,  or  a  computerized  representation  of  a  particu¬ 
lar  situation,  may  be  created  in  the  computer  language  of  the 
modeler’s  choosing.  FORTRAN,  COBOL,  or  even  Basic  Assembler 


Language  could  be  used,  albeit  with  a  great  deal  of  detail 
and  difficulty,  as  the  modeling  mechanism.  Fortunately, 
simulation  languages  featuring  more  concise  coding  schemes 
than  standard  FORTRAN  have  been  developed  to  facilitate  and 
enhance  the  modeler's  efforts  to  obtain  meaningful  predictive 
results.  SIMSCRIPT  and  GPSS  are  two  such  languages  that  are 
highly  regarded  by  those  familiar  with  their  capabilities. 

A  GPSS  simulation  of  the  requisition  throughput  process 
at  NSC  San  Diego  was  developed  in  1973  as  an  NPS  (Naval  Post¬ 
graduate  School)  thesis.  This  effort,  which  is  specified  as 
reference  (b)  in  this  study,  was  an  exceptionally  well  conceived 
undertaking  that  possesses  enormous  predictive  value  in  the 
hands  of  personnel  schooled  in  GPSS.  Unfortunately,  Naval 
Supply  Center  resource  constraints  and  workload  levels  generally 
prohibit  the  luxury  of  maintaining  simulation  specialists  on 
their  roles.  In  the  absence  of  such  expertise,  not  only  is  an 
on-site  capability  to  expand  upon  the  existing  GPSS  model  missing 
but,  more  importantly,  the  modeling  details  used  in  the  study 
can  not  be  comprehended.  The  actual  functions  being  performed 
by  specific  GPSS  coding  is  not  readily  apparent.  Explanatory 
data  is  provided  either  through  accompany  textual  explanations 
or  by  the  inclusion  of  comment  cards  at  strategic  locations  within 
the  GPSS  deck.  In  general,  except  for  accompanying  flow  charts 
and/or  block  diagrams,  there  is  no  recognized  graphic  technique 
to  provide  a  visual  display  that  corresponds  to  the  GPSS  (or 
SIMSCRIPT)  coding  in  the  model. 


This  project  duplicates  the  1973  study  in  the  sense  that 
its  long  range  goals  include  the  simulation  of  requisition 
throughput  at  NSC  San  Diego  and  the  analysis  of  numerous  alterna 
tive  processing  methods.  There  the  similarity  ends.  Based  on 
the  premise  that  a  picture  is  worth  a  thousand  words,  the  NSC 
San  Diego  requisition  processing  model  is  developed  in  a  rela¬ 
tively  new  simulation  language  called  Q-GERT.  Under  the  addi¬ 
tional  assumption  that  NSC  San  Diego  would  prefer  to  acquire  and 
maintain  an  on-site  simulation  capability,  the  development  of 
the  model  becomes  the  vehicle  for  the  introduction  and  explana¬ 
tion  of  the  simulation  language  itself.  Therefore,  the  basic 
dual  purpose  short  term  objective  becomes  the  description  of 
Q-GERT  concepts  and  modeling  techniques  in  sufficient  depth  to 
both  familiarize  stock  point  personnel  with  the  language  and 
provide  an  initial  version  of  a  model  that  accurately  portrays 
requisition  processing  at  NSC  San  Diego. 

An  on-site  simulator  is  obviously  not  a  necessity.  Intelli¬ 
gent  decisions  regarding  the  consequences  of  proposed  procedural 
changes  can  often  be  made  without  the  aid  of  a  simulated  impact 
assessment.  Furthermore,  if  a  detailed  familiarity  with  the 
simulator  is  considered  either  nonessential  or  inadvisable  in 
view  of  the  demands  on  existing  personnel,  simulations  can  be 
conducted  by  external  sources;  e.g.,  the  GPSS  model  could  be 
updated  and  used  to  model  alternatives  selected  by  NSC  San  Diego 
There  is,  however,  no  guarantee  that  adequate  external  resources 
will  be  available  when  needed.  Furthermore,  there  is  always  a 
possibility  that  the  alternatives  modeled  may  differ  to  some 
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degree  from  those  specified  by  NSC  San  Diego.  Finally,  as 
explained  below,  model  formulation  useing  Q-GERT  begins  by 
developing  structured  network  symbology  from  which  the  trans¬ 
lation  to  the  simulation  cards  is  directly ^accomplished .  There¬ 
fore,  the  maintenance  of  an  on-site  Q-GERT  simulator  equates 
to  the  existence  of  a  current  graphic  representation  of  the 
requisition  processing  system.  The  first  step  in  evaluating 
any  proposed  change  is  to  revise  the  graphics  of  the  affected 
network  segment.  Therefore,  the  revised  network  symbology  hs 
already  been  completed  if  the  change  is  subsequently  incorporated 
into  the  system. 

There  are  both  training  and  data  processing  costs  associated 
with  simulating  on-site.  Personnel  must  be  trained  in  the  Q-GERT 
symbology  and  input  card  development.  This  study  describes  a 
majority  of  the  network  graphics  and  their  purpose.  The  reference 
(a)  text  by  A.  Alan  B.  Pritsker,  the  developer  of  Q-GERT,  pro¬ 
vides  a  field-by-field  description  of  each  required  card  type. 

There  are  basically  two  approaches  that  can  be  taken  to  ac¬ 
quire  a  Q-GERT  data  processing  capability.  The  language  may 
be  purchased  from  Pritsker  and  Associates  and  loaded  locally  on 
disk  or  some  other  peripheral  device.  There  may  be  significant 
problems  encountered  with  this  approach  if  the  intent  is  to 
use  existing  Burroughs  equipment.  First,  the  Q-GERT  language 
is  coded  in  ANSI  FORTRAN,  which  can  not  be  directly  compiled 
by  Burroughs  equipment.  The  differences  in  the  Burroughs  ver¬ 
sion  of  FORTRAN  are  not  major,  but  some  comrersion  would  be 
needed.  Secondly,  the  core  requirement  to  load  the  1,000  node 
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version  of  Q-GERT  will  be  large.  personnel  can  provide 

information  on  core  requirements  and  run  times  for  the  smaller 
100  node  version.  Pritsker  and  Associates,  whose  address  and 
telephone  number  are  included  in  the  Distribution  List,  may  be 
able  to  address,  or  even  refute,  the  Burroughs  incompatibility 
problem.  They,  of  course,  are  the  only  source  for  pricing 
information  on  the  cost  of  acquiring,  and  perhaps  installing, 
the  1,000  node  version  of  Q-GERT.  It  should  be  noted  that  the 
purchase  and  installation  of  Q-GERT  at  a  local  activity  having 
IBM  equipment,  if  there  is  such  an  activity,  is  a  feasible 
alternative.  Programs  could  be  submitted  either  through  card 
or  remote  input  and  the  FORTRAN  compatibility  problem  would  be 
avoided . 

The  second  approach  for  acquiring  a  Q-GERT  capability  con¬ 
sists  of  obtaining  remote  access  to  an  activity  that  has  already 
purchased  the  language.  NPS  is  such  an  activity  and,  although 
only  the  100  node  version  is  currently  operational,  the  necessary 
1,000  node  capability  will  be  established  in  the  near  future. 

NPS  can  provide  the  details  and  costs  associated  with  the  remote 
access  approach.  It  suffices  to  note  that  the  initial  model, 
or  revised  versions,  would  be  maintained  on  NPS  disks,  accessed 
through  a  telephone  remote,  and  activated  by  means  of  a  standard 
password  procedure. 

The  main  advantage  of  an  on-site  simulation  capability  is 
the  flexibility  it  provides  in  the  analysis  of  proposed  system 
changes  ranging  from  the  reallocation  of  existing  resources  to 
the  addition  of  completely  new  functional  areas.  As  Chapters  1 


through  10  are  reviewed,  knowledgeable  NSC  San  Diego  will  iden¬ 
tify  numerous  additional  alternatives  that  could  be  evaluated; 
the  very  process  of  tracing  transaction  flow  through  the  model 
creates  speculation  about  the  impact  of  doing  things  differ¬ 
ently.  The  Q-GERT  concept  of  graphically  displaying  the  model 
contributes  to  a  better  understanding  of  the  system  being  modeled 
and  facilitates  the  identification  of  processing  alternatives. 

It  is  not  difficult  to  imagine  the  system  graphics  serving  as 
a  training  device  for  Management  Analysts  and  Planning  Depart¬ 
ment  personnel . 

NSC  San  Diego  is  requested  to  assess  the  potential  of  the 
model  developed  for  on-site  use  and  advise  Professor  F.  R. 
Richards  of  NPS ,  autovon  878-2543,  of  their  findings.  If  the 
aforementioned  costs,  which  are  quantifiable,  are  considered 
prohibitive  regardless  of  the  potential  benefits,  then  a  recom¬ 
mendation  of  no  further  effort  in  this  area  is  appropriate.  A 
management  review  of  the  model  development  chapters  may  still 
be  useful;  processing  procedures  must  necessarily  be  described 
during  the  detailed  discussion  of  the  model  and  alternatives 
to  some  current  operating  practices  have  been  presented. 

If  model  validation  and  actual  simulation  runs  are  considered 
paramount  for  the  NSC  San  Diego  decision,  funding  for  a  second 
thesis  effort  when  the  1,000  node  model  is  operational  will 
probably  be  necessary.  If  the  capability  is  unequivocably  de¬ 
sired,  the  funding  of  a  second  thesis  project  would  still  appear 
to  contribute  to  an  orderly  implementation  process.  The  stu¬ 
dent,  a  Supply  Corps  officer  familiar  with  both  Q-GERT  and 
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stock  point  operations,  would  be  available  for  consultation 
on-site  regarding  model  validity,  possible  revisions,  and  the 
identification  of  processing  alternatives  to  be  tested.  With 
the  1,000  node  model  and  the  initial  Q-GERT  card  deck  at  his 
disposal  at  NPS,  the  student  could  verify  (debug)  the  model 
prior  to  arrival  at  NSC  San  Diego. 

In  grand  design,  an  expanded  version  of  this  model  could 
develop  into  a  stock  point  simulator.  The  existence  of  a  revi¬ 
sion  representing  each  major  stock  point  can  realistically  be 
envisioned.  However,  if  the  enclosed  humble  beginning  is  ever 
perceived  as  evolving  and  expanding  to  that  degree,  a  few  pre¬ 
liminary  cautions  should  be  heeded.  As  detailed  as  the  figures 
in  Chapters  6-10  may  appear,  this  model  version  may  be  viewed  as 
sacrificing  efficiency  for  the  sake  of  illustrative  symbology. 
Consequently,  some  rather  cumbersome  adaptations  of  basic  Q-GERT 
concepts  were  used  in  place  of  more  efficient  programming  methods; 
e.g.,  the  messenger  service  modeling  approach  described  in  Chap¬ 
ter  6.  The  efficiency  can  be  improved  through  the  development 
of  FORTRAN  program  segments  to  replace  the  more  inefficient  seg¬ 
ments  of  the  model.  The  use  of  such  program  inserts,  which 
serve  to  provide  Q-GERT  a  practically  unlimited  modeling  capa¬ 
bility,  was  deliberately  avoided  in  this  study;  FORTRAN  insert 
functions  cannot  be  described  using  standard  Q-GERT  symbology 
and  their  use  obscures  the  graphic  details  associated  with  that 
segment  of  transaction  processing.  Simply  stated,  the  objective 
was  to  provide  detailed  graphics  and  guidance  on  Q-GERT,  not 
FORTRAN.  Based  on  the  review  of  this  study  by  Pritsker  and 
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Associates,  it  may  be  recommended  that  any  universal  acceptance 
and  subsequent  development  of  a  stock  point  simulator  concept 
be  accompanied  by  a  switch  to  a  simulation  language  called 
SLAM,  which  can  be  categorized  as  a  combination  of  Q-GERT  and 
SIMSCRIPT.  Regardless  of  the  approach  ultimately  taken  to 
improve  model  efficiency,  this  simplistic  initial  version  re¬ 
mains  a  logical  starting  point. 

The  model  was  designed  to  accommodate  expansion  when,  or 
if,  such  an  action  becomes  desirable.  Areas  where  expansion 
might  be  considered  are  mentioned  throughout  Chapters  6  through 
IQ.  Chapters  2  through  4  describe  an  extremely  simplified  re¬ 
quisitioning  processing  system  and  introduce  the  Q-GERT  concepts 
and  symbology  needed  to  model  that  system.  Additional  Q-GERT 
concepts  that  will  be  used  in  later  chapters  are  also  covered 
in  detail. 

Chapter  5  contains  an  extremely  detailed  discussion  of  re¬ 
quisition  processing  at  NSC  San  Diego.  Requisition  categoriza¬ 
tion  and  processing  specifics  for  each  category,  demand  excep¬ 
tion  workload  and  processing,  POE  and  autodin  demand  data,  and 
the  scheduling  of  demand  processing  runs  are  among  the  topics 
presented. 

Chapters  6  through  10  introduce  additional  Q-GERT  concepts 
as  they  are  used,  provide  the  graphic  representation  of  a  par¬ 
ticular  functional  area  or  process  such  as  autodin  arrivals,  and 
give  a  detailed  description  of  transaction  flow  through  the 
network  segment.  Chapters  6  through  9  cover  the  basic  model 
from  requisition  arrival  and  categorization  (Chapter  6)  to  the 
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movement  of  material  from  local  delivery  or  to  shipping  (Chap¬ 
ter  9) .  Chapter  10  is  devoted  entirely  to  the  timing  of  resource 
availability  (personnel,  ADP,  messenger,  etc.)  and  the  shifting 
of  daily  demand  patterns.  , 

Chapter  11  delineates  modeling  techniques  that  should  be 
closely  reviewed  during  the  verification  process,  suggests 
alternative  requisition  processing  schemes  that  could  be  evalu¬ 
ated  in  a  subsequent  thesis  effort,  if  forthcoming,  and  provides 
concluding  comments  that  include  a  sincere  statement  of  grati¬ 
tude  to  the  many  NSC  San  Diego  employees  who  were  most  unselfish 
with  both  their  time  and  assistance. 

It  is  regrettable  that  time  constraints  and  the  nonavaila¬ 
bility  of  the  larger  (1,000  node)  Q-GERT  version  combined  to 
preclude  either  full  model  or  segmented  simulation  runs.  Sam¬ 
ples  of  standard  Q-GERT  output,  which  was  the  only  statistical 
data  programmed  in  the  initial  version,  may  be  obtained  from 
either  NPS  or,  one  would  assume,  from  Pritsker  and  Associates. 
Reference  (a) ,  Modeling  and  Analysis  Using  Q-GERT  Networks , 
contains  numerous  and  excellent  examples  with  accompanying 
illustrations  of  standard  Q-GERT  output.  A  segmented  approach 
to  running  the  model,  which  contains  over  400  nodes,  posed  the 
problem  of  defining  a  segment  of  less  than  100  nodes  that  could 
be  meamingfully  interpreted.  Since  developing  such  a  model 
involved  extraction  of  segments  from  all  chapters,  the  ultimate 
requirement  was  the  development  of  a  completely  new  model,  a 
process  that  simply  could  not  be  accomplished  in  the  limited 
time  remaining. 
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II.  THE  SIMPLIFIED  MODEL 

Figure  2-1  depicts  an  extremely  simplified  version  of  the 
requisition  processing  procedure.  It  represents  the  basic  • 
functions  that  must  be  performed  at  any  stock  point  to  process 
a  customer  request  and  effect  the  subsequent  issue  of  the 
required  material.  Inherent  in  the  procedure  illustrated  are 
numerous  assumptions  that  are  initially  made  to  facilitate 
introduction  of  basic  Q-GERT  symbology  at  the  least  detailed 
level  possible. 
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Figure  2-1.  Simplified  Requisition  Processing  Model 


First,  it  is  hypothesized  that  each  requisition  is  processed 
in  an  identical  manner;  i.e.,  there  is  initially  no  priority 
scheme  that  distinguishes  one  request  from  another  and  each 
requisition  must  be  processed  by  all  system  components. 

Secondly,  it  is  initially  assumed  that  each  request  results 
in  an  issue.  Gone  for  the  time  being  are  such  minor  annoyances 
as  editing  and  keypunch  errors,  nonavailability  of  material 
whether  NIS  (Not  in  Stock)  or  NC  (Not  Carried) ,  demand  processing 
exceptions,  and  warehouse  refusals.  However,  these  and  other 
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actual  processing  techniques  that  are  more  representative 
of  actual  system  operation  will  beintroduced  as  the  Q-GERT 
model  is  expanded  to  incorporate  system  complexities. 

Figure  2-2  represents  the  Q-GERT  symbology  corresponding 
to  the  basic  system  described  above.  This  system  will  be 
discussed  at  a  level  of  detail  sufficient  to  serve  as  the 
mechanism  for  the  introduction  of  basic  Q-GERT  concepts  as 
described  in  Chapter  2  of  reference  (a)  . 
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Figure  2-2.  The  Q-GERT  Simplified  Model 


Inasmuch  as  this  graphical  representation  contains  a  series 


of  slightly  dissimilar  nodes  connected  by  branches  it  will 
henceforth  be  designated  a  Q-GERT  network.  The  nodes  are  iden¬ 
tified  by  the  number  in  the  far  right  partition.  Node  function 
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varies  by  type  and  each  node  illustrated  is  discussed  in  de¬ 
tail  below.  Network  activities  -  editing,  keypunch,  etc.,  - 
are  performed  on  the  branches  of  the  network  and  are  identified 
by  the  number  in  the  box  under  the  branch;  e.g.,  the  designation 
j~2~j  represents  the  edit  activity  of  function.  Branches  generally 
represent  the  passage  of  time,  or  service  time,  in  the  network. 
When  specified,  the  circled  number  beside  the  activity  number 
beneath  the  branch  indicates  the  number  of  identical  servers 
available  to  perform  the  required  activity. 

Transactions,  in  this  case  requisitions,  flow  through  the 
network  and  are  serviced  on  the  network  branches.  Node  1,  the 
source  node,  functions  as  a  demand  generator  and  will  be  dis¬ 
cussed  later.  It  suffices  to  note  that  the  arriving  transac¬ 
tions/demands  are  initially  processed  at  the  editing  station 
represented  by  activity  2.  Since  there  are  only  three  Q) 
servers  available  to  perform  the  edit  function,  it  is  likely 
that  the  requisitions  will  have  to  await  service.  Hence  the 
insertion  of  node  2,  a  queue  node  (Q-node) ,  between  the  source 
node  and  the  edit  activity.  In  fact,  service  activities  are 
always  preceeded  by  Q-nodes  and,  for  the  time  being,  only  by 
Q-nodes , 

A  description  of  the  partitions  in  queue  node  2  is  provided 
in  Figure  2-3.  Note  that  the  remaining  Q-nodes  in  this  simpli¬ 
fied  network,  nodes  3  through  8,  are  identical  except  for  the 
node  number  associated  with  each.  All  are  initialized  with 
zero  transacticns/demands  awaiting  service  and  there  is  no 
limit  on  the  number  of  transactions  that  can  accumulate  at  each 
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Procedure  for  ranking 
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F  =  FIFO  (First  in,  first  out) 
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Node  number 


Figure  2-3.  The  Q-Node 

queue.  Finally,  since  the  requisitions  are  indistinguishable 
by  assumption,  they  are  simply  processed  sequentially,  or  first- 
in-first-out  as  indicated  by  the  F  in  the  center  partition. 

Other  ranking  possibilities  and  techniques  will  be  discussed 
later.  However,  it  should  be  emphasized  at  this  time  that  Q- 
nodes  preceed  service  activities  and  the  ranking  of  transac¬ 
tions  (demands)  is  accomplished  solely  to  designate  which  item 
will  be  processed  by  the  next  available  server  from  the  activity 
immediately  following  the  Q-node. 

Figure  2-4  provides  a  similar  overview  of  the  source  node, 
node  1,  partitions.  Designation  of  the  upper  middle  partition 
is  deliberately  omitted.  Alternatives  to  the  M  specification 
in  the  lower  middle  portion  will  be  introduced  later.  Since 
the  node  illustrated  is  a  source  node,  the  M  designation  is 
basically  redundant.  Each  transaction  generated  at  a  source 
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Figure  2-4.  The  Source  Node 

node  is  automatically  assigned  a  mark  time  representing  the 
transaction  time  of  origin.  Unless  subsequently  altered,  this 
mark  time  will  accompany  the  transaction  through  the  network 
and  is  defined  as  a  transaction  attribute.  Note  that  there 
are  two  branches  emanating  from  the  source  node.  With  only 
one  transaction  required  to  release  this  node  as  indicated  in 
the  bottom  left  partition,  each  nodal  release  will  result  in 
identical  transactions  being  routed  along  both  the  branch/activity 
labeled  13  and  the  activity  labeled  1.  This  node  serves  as  an 
example  of  the  deterministic  branching  process  in  Q-GERT.  The 
transaction  could  have  been  routed  along  numerous  other  branches. 
When  deterministic  branching  is  used,  the  release  of  a  node 
leads  to  the  routing  of  an  identical  transaction  on  each  branch. 
Note  that  there  are  no  server  designations  on  either  of  the 
branches  from  the  source  node.  Since  this  node  is  not  a 
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Q-node,  the  activity  following  it  can  not  be  a  service 
activity  . 

It  has  been  noted  that  network  branches  represent  the 
passage  of  time.  The  notation  (EX,1)  above  the  activity  1 
designator  represents  the  specified  method  for  computing  the 
delay  between  releases  of  node  1.  This  delay  represents  the 
time  between  arrival  of  demands  and  (EX,1)  indicates  that  the 
delay  will  be  taken  from  an  exponential  distribution  with 
parameters  defined  in  parameter  set  one.  The  Q-GEJRT  input  cards 
will  contain  both  an  ACT  card  to  describe  activity  1  and  a  PAR 
card  providing  the  required  parameter  values  for  an  exponential 
distribution.  Numerous  distributions  are  available  to  model 
activity  times.  Appendix  A  lists  those  discussed  in  reference 
(a) .  Note  on  Figure  2-2  that  activities  4  and  5  feature  normally 
distributed  service  times  with  parameter  set  numbers  2  and  3 
providing  the  appropriate  distributional  information.  Activi¬ 
ties  6  and  8  exhibit  service  times  from  a  uniform  distribution 
described  in  the  indicated  parameter  sets.  However,  the  speci¬ 
fication  CO  for  activities  2,  3,  and  7  represents  a  constant 
function  and  the  number  following  CO  is  the  number  of  time  units 
required  to  perform  the  activity.  Finally,  activity  13  between 
nodes  1  and  2  indicates  both  that  activity  numbering  need  not 
be  sequential  and  that  a  branch  need  not  represent  the  passage 
of  time.  The  absence  of  an  activity  time  designation  consti¬ 
tutes  a  (CO,0)  distributional  assumption  or  a  zero  passage  of 
time.  Therefore,  the  requisition  arrival  time  corresponds  to 
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entry  into  the  edit  queue  in  the  Q-GERT  simplified  model  depicted 
in  Figure  2-2. 

Node  9  in  Figure  2-2  need  not  be  labeled  here.  The  I  in 
the  bottom  middle  partition  indicates  that  interval  statistics 
are  to  be  collected;  i.e.,  the  difference  between  the  time  of 
arrival  at  node  9  and  the  time  of  origin  at  node  1.  Otherwise 
each  partition  is  defined  exactly  like  the  source  node  illus¬ 
trated  -in  Figure  2-4.  The  initial  and  each  subsequent  arrival 
of  a  transaction,  the  material  necessary  to  satisfy  a  demand, 
will  release  node  9  and  prompt  the  collection  of  interval  sta¬ 
tistics  representing  that  requisition's  time  in  the  system. 

The  inclusion  of  the  symbol  — ^vw -»  on  the  right  side  of  node  9 
serves  to  designate  it  as  a  sink  node.  If  the  symbol  were 
omitted  and  the  transaction  routed  elsewhere,  this  node  would 
be  categorized  as  a  statistics  node.  A  sink  node  can  be  viewed 
as  the  mechanism  by  which  a  completed  transaction  departs  the 
network.  Q-GERT  simulation  runs  are  often  terminated  on  the 
basis  of  a  specified  number  of  sink  node  releases. 
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III.  DISCUSSION  OF  THE  SIMPLIFIED  MODEL 

An  intuitive  appraisal  of  the  Figure  2-2  simplified  model 
leads  to  the  conclusion  that  it  does  not  represent  a  particu¬ 
larly  challenging  problem.  Simulation  runs  would  lead  to  the 
automatic  generation  of  relevant  Q-node  and  service  activity 
statistics  by  the  Q-GERT  Analysis  Program.  These  statistics 
include  average  number  of  transactions  in  each  queue  and  server 
utilization  data.  Therefore,  assuming  activity  and  arrival 
distributional  assumptions  are  correct,  the  simulations  would 
be  most  useful  for  identifying  potential  backlog  problems  and 
excess  or  inadequate  resources  at  each  service  activity.  If 
the  servers  could  be  used  at  any  activity  within  the  network  , 
the  simulation  runs  could  be  used  to  generate  the  "best"  possi¬ 
ble  allocation  of  resources  within  specified  constraints. 
Nevertheless,  the  simplified  model  is  useful  as  a  basis  for 
the  introduction  of  Q-GERT  symbology  and  as  a  point  of  departure 
for  modeling  the  NSC  San  Diego  requisition  processing  procedure. 

The  number  of  servers  assigned  to  each  Figure  2-2  activity 
and  the  specified  service  time  distributions  are  strictly  hypo¬ 
thetical  and  used  only  for  Q-GERT  illustrative  purposes.  As 
the  NSC  San  Diego  model  is  developed,  the  service  times  assigned 
will  generally  be  identical  to  those  used  in  reference  (b) ,  which 
were  based  on  the  DIMES  (Defense  Integrated  Management  Engineer¬ 
ing  Systems)  study  specified  in  reference  (c)  and  conducted  in 
1968.  Departures  from  the  use  of  these  standards,  which  are  of 

24 


"*  ■*»  < 


dubious  validity  if  only  due  to  technical  innovations  in  the 
last  12  years,  will  be  noted  during  the  model  development.  It 
should  be  emphasized  at  this  point  that  the  usefulness  of  any 
Q-GERT  model  is  directly  related  to  the  validity  of  the  service 
time  assumptions  which,  if  correctly  established,  emanate  from 
a  series  of  time  and  motion  studies  that  provide  a  represen¬ 
tative  sample  of  service  times  as  an  input  to  curve  fitting 
tests.  This  procedure  enables  the  modeler  to  express  a  degree 
of  confidence  in  his  results  rather  than  placing  the  validity 
of  his  model  at  the  mercy  of  the  distributional  assumptions. 
Unfortunately,  the  latter  undesirable  situation  happens  to  be 
the  case  in  this  model.  Time  constraints  precluded  the  develop¬ 
ment  of  current  standards  for  each  service  activity.  Fortunately, 
however,  more  accurate  standards  can  easily  be  incorporated  into 
the  existing  model.  The  activity  card  and,  if  necessary,  the 
accompanying  parameter  card  corresponding  to  this  service  activity 
must  be  changed  to  correspond  to  the  new  service  time  distribution 
annotated  on  the  revised  branch. 

As  a  final  comment  on  Figure  2-2,  the  function  performed 
by  activity  4,  records  update  and  issue  document  preparation, 
is  basically  a  mechanized  function  performed  by  the  computer 
CPU  (Central  Processing  Unit)  in  conjunction  with  appropriate 
peripheral  equipment.  In  the  simple  model  this  process  can 
be  visualized  either  as  a  completely  manual  or  partially  auto¬ 
mated  activity.  How  it  is  done  is  basically  irrelevant;  the 
important  factor  is  the  validity  of  the  assumption  regarding 
how  long  it  takes  to  perform  the  function. 
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This  concludes  the  discussion  of  the  simplified  model 
featuring  sequential  requisition  processing  through  a  series 
of  service  activities  with  all  transactions  (requisitions/ 
demands)  being  satisfied.  Perhaps  such  a  model  would  be  appro¬ 
priate  for  a  company  such  as  a  discount  stereo  distributor  who 
begins  each  day  with  a  zero  backlog  (initial  number  of  transac¬ 
tions  in  each  queue  is  zero) ,  receives  telephone  orders  for  a 
specified  time  period  each  day,  always  satisfies  each  order 
through  various  local  sources,  and  closes  when  all  orders  have 
been  staged  for  delivery.  As  illustrated,  however,  the  Figure 
2-2  model  wouldn't  provide  an  accurate  assessment  of  the  stereo 
distribution  process  because  it  lacks  a  timing  mechanism  to 
terminate  the  arrival  of  transactions  (orders)  while  permitting 
existing  orders  to  be  fully  processed.  Q-GERT  timing  logic 
will  be  introduced  in  the  course  of  the  model  development  that 
follows.  However,  before  beginning  to  develop  the  NSC  San  Diego 
processing  procedures,  some  additional  basic  Q-GERT  concepts 
must  be  presented. 
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IV .  ADDITIONAL  BASIC  Q-GERT  CONCEPTS 

A.  THE  REGULAR  NODE 

Figure  4-1  depicts  the  most  common  Q-GERT  node,  the  regular 
node.  In  general,  the  regular  node  functions  to  route  trans¬ 
actions  and  assign  attributes  as  discussed  later  during  the 
model  development. 
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\  upon  node  release. 

- Node  number 


Blank  for  a  regular 
node.  Insertion  of  statistics 
gathering  specification  makes 
the  node  a  statistics  node 


Figure  4-1.  The  Regular  Node 

The  use  of  the  middle  partitions  will  be  discussed  below  when 
the  accumulation  of  transactions  is  addressed.  These  parti¬ 
tions  deal  with  a  decision-making  process  based  on  attribute 
values  which  will  be  introduced  later.  The  only  attribute 
encountered  thus  far  is  the  automatically  assigned  mark  time 
designator.  When  not  used  to  assign  attributes  or  accumulate 
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transactions,  the  regular  node  usually  appears  in  the  simple 
form  illustrated  in  Figure  4-2. 


For  initial 


Node  number 


Figure  4-2.  The  Simple  Regular  Node 


Note  that  the  value  1  for  initial  and  subsequent  release  indi¬ 
cates  that  no  accumulation  of  transactions  is  taking  place. 
Therefore,  there  is  no  requirement  for  a  center  partition.  The 
converse  is  not  true,  however.  Values  other  than  1  could  be 
assigned  to  the  initial  and  subsequent  release  partitions  with 
no  center  partition  defined.  In  that  case,  the  default  values 
for  the  center  partitions  shown  in  Figure  4-1  will  be  assigned. 

The  regular  node  functioning  as  a  transaction  accumulator 
is  illustrated  in  Figure  4-3.  It  may  appear  in  either  of  the 
forms  indicated. 
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Coding  for  specified  statistic  would  make  it  a 
Statistics  Node 


Figure  4-3.  Regular  Node  as  a  Transaction  Accumulator 
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The  partitions  are  defined  on  Figures  4-1  and  4-2.  The  value 
of  2  for  initial  and  subsequent  nodal  release  is  an  example 
only.  The  possible  values  for  the  upper  middle  partition  are 
shown  and  represent  First,  Last,  Smallest,  and  Biggest,  respec¬ 
tively.  This  accumulator  function  serves  to  eliminate  trans¬ 
actions  in  the  network.  The  required  accumulation  of  input 
transactions  leads  to  the  release  of  only  one  transaction. 
Therefore,  since  each  transaction  possesses  at  least  one  attri¬ 
bute,  the  mark  time,  and  often  more  than  one,  it  is  necessary 
to  designate  which  transaction's  attributes  will  be  routed  when 
the  node  is  released.  An  F  designation  specifies  "route  the 
first  transaction's  attributes";  similarly,  the  L  indicates 
the  last  transaction's  attributes  should  be  routed.  However, 
when  B  or  S  is  used  in  the  upper  segment,  the  indicated  /x 
symbol  should  accompany  it  since  x  designates  the  relevant 
attribute.  Therefore,  B  or  S  indicates  that  the  attributes 
of  the  transaction  having  the  Biggest  or  Smallest  value  of 
attribute  x  should  be  routed.  For  example,  the  dollar  value 
of  a  requisition  may  be  assigned  as  an  attribute  of  that  trans¬ 
action.  Then  the  requisition  having  the  highest  dollar  value 
could  be  selected  from  an  accumulation  of  demands.  Note  that 
an  M  may  be  used  instead  of  an  integer  x.  The  M  represents 
the  mark  time  of  the  transaction.  In  the  absence  of  a  center 
partition,  the  attributes  associated  with  the  last  arriving 
transaction  are  routed.  The  accumulation  function  was  introduced 
to  illustrate  the  diversity  of  Q-GERT.  Since  each  requisition 
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must  be  processed  in  the  NSC  San  Diego  model,  accumulation 
of  transactions  will  not  play  a  direct  role  in  subsequent 
model  development. 


B.  BALKING  AT  Q-NODES 

Q-nodes  will  now  be  revisited  to  illustrate  the  concepts 
of  balking  and  blocking.  Figure  4-4  is  a  labeled  Q-node  and 
is  similar  to  the  Q-node  specified  in  Figure  2-3. 

Initial 
number 
in  queue 

Maximum 
number  in 
queue 

Figure  4-4.  The  Q-Node  Revisited 

Recall  that  a  service  activity  follows  a  Q-node;  in  this  case, 
service  activity  2  featuring  3  servers  is  indicated.  If  an 
initial  number  in  the  queue  other  than  zero  is  specified,  Q- 
GERT  assumes  that  all  servers  are  busy  and  schedules  service 
time  completions  accordingly.  Therefore,  placing  a  2  in  the 
initial  number  section  of  Q-node  2  indicates  there  are  5  trans¬ 
actions  in  the  system;  i.e.,  2  awaiting  service  and  3  being 
serviced  by  the  servers  in  activity  2. 

The  queue  capacities  illustrated  thus  far  have  been  infinite. 
Suppose  Q-node  2  above  has  a  maximum  queue  capacity  of  6. 

Further  assume  that  the  queue  is  "full"  and  a  seventh  transaction 
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arrives.  This  additional  transaction  can  not  be  accommodated 
at  Q-node  2.  Therefore,  Q-GERT  permits  the  modeling  of  trans¬ 
action  balking  as  illustrated  in  Figure  4-5  or,  if  appropriate, 
blocking  of  the  service  activity  preceding  Q-node  2  (Figure  4-6) 


Sink  Node 


IAJ 


Figure  4-5.  Balking 

The  balking  situation  illustrated  on -the  left  of  Figure  4-5  pro¬ 
vides  for  the  return  of  the  transaction  to  the  Q-node  after  one 
time  unit  (C0,1)  until  the  transaction  is  accepted.  The  dot- 
dash  line  represents  a  balking  action  which  would  be  described 
on  the  Q-GERT  card  corresponding  to  Q-node  2.  Therefore,  there 
will  be  no  activity  card  describing  the  dot-dash  branch  from 
Q-node  2  to  regular  node  3.  In  fact,  nonsolid  branches,  and 
others  will  be  encountered,  are  not  considered  activities  by 
Q-GERT.  The  balking  scenario  depicted  on  the  right  side  of 
Figure  4-5  depicts  a  transaction  being  balked  out  of  the  net¬ 
work  while  having  interval  statistics  maintained  at  the  sink 
node . 
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C.  BLOCKING  SERVICE  ACTIVITIES 

Figure  4-6  illustrates  the  phenomena  of  blocking  that  can 
occur  when  a  service  activity  output  is  routed  to  a  Q-node  with 
a  finite  queue  capacity. 


Figure  4-6.  Blocking 

This  situation  occurs  when  Q-node  2  is  at  its  capacity  and 
the  servers  at  activity  1  can  not  proceed  until  the  transaction 
just  completed  can  be  transferred  to  the  Q-node  for  activity  2. 
Specifically,  blocking  occurs  if  at  least  one  of  the  two  servers 
at  activity  1  has  completed  an  activity  but  can  not  begin  to 
process  another  transaction  from  the  Q-node  (not  shown)  pre¬ 
ceding  activity  1  due  to  the  inability  of  Q-node  2  to  accept 
another  transaction.  If  the  blocking  function  is  included  in 
a  model,  it  will  be  indicated  on  the  Q-GERT  card  describing 
Q-node  2 . 

D.  PROBABILISTIC  BRANCHING 

Thus  far  all  branches  leaving  the  nodes  described  were 
deterministic.  That  is,  each  release  of  the  node  resulted  in 
the  transaction (s)  released  being  routed  along  each  branch. 

Prior  to  commencing  the  model  formulation,  probabilistic  branching 
must  be  addressed.  Figure  4-7  illustrates  probabilistic 
branching  from  a  regular  node. 


(NO, 3) 
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Figure  4-7.  Probabilistic  Branching 
A  transaction  leaving  node  1  will  take  branch/activity  6  with 
a  probability  of  0.8  and  will  encounter  a  constant  2  time  unit 
delay  while  traversing  that  branch.  Conversely,  activity  7 
with  its  constant  5  time  unit  delay  will  be  undertaken  with 
probability  0.2.  Therefore,  a  transaction  leaving  node  1  will 
take  one  branch  or  the  other,  but  never  both  as  in  deterministic 
branching.  The  symbol  on  the  right  side  of  regular  node 

one  contains  the  node  number  and  indicates  that  probabilistic 
branching  applies.  Naturally,  the  sum  of  the  probabilities  on 
the  branches  leaving  the  node  must  equal  1.  Both  probabilistic 
and  conditional  branching,  which  will  be  introduced  when  used, 
will  often  be  encountered  in  the  NSC  San  Diego  model. 

E.  Q-GERT  INPUT  CARD  OVERVIEW 

Finally,  some  additional  comment  on  the  cards  required  to 
actually  conduct  an  analysis  of  a  Q-GERT  network  is  required. 
Perhaps  the  most  impressive  feature  of  Q-GERT  is  that  the  vast 
majority  of  the  input  cards  are  created  directly  from  the 


graphical  representation  of  the  network.  In  general,  there 
is  a  card  corresponding  to  each  node,  each  activity,  and  each 
parameter  set  referenced  to  describe  an  activity  duration. 

This  series  of  cards  plus  a  GEN  card  to  provide  initializing 
data  and  simulation  termination  rules  and  a  FIN  card  to  signal 
the  end  of  the  data  describing  the  network  are  all  that  are 
needed  to  effect  a  simulation  of  basic  Q-GERT  networks.  Although 
the  situation  becomes  more  complex  as  subnetworks  are  added, 
reference  (a)  provides  excellent  formats  describing  the  fields 
of  all  required  input  cards.  Therefore,  a  detailed  description 
of  input  card  development  will  not  be  included. 
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V.  NSC  SAN  DIEGO  DEMAND  PROCESSING  DISCUSSION 


A.  REQUISITION  CATEGORIZATION 

NSC  San  Diego  customer  demand  can  be  divided  into  the  two 
major  categories  of  autodin  and  POE  (Point  of  Entry) .  Auto¬ 
din  requisitions  are  further  subdivided  into  IPG  (Issue  Pri¬ 
ority  Group)  I,  II,  and  III  requests  since  response  time 
standards  established  by  reference  (d)  necessitate  different 
processing  methods  for  each  category.  POE  requisitions  are 
also  processed  according  to  IPG.  However,  further  subdivisions 
within  each  IPG  must  be  considered  if  the  model  is  to  resemble 
reality.  For  example,  POE  IPG  I  requisitions  can  either  be 
"Bearers"  (Walk-Throughs)  or  be  unaccompanied  such  as  a  message 
requisition.  POE  IPG  II  transactions  may  be  QUICK  PIC,  un¬ 
accompanied,  or,  to  a  limited  degree,  special  program  requests. 
Finally,  POE  IPG  III  transactions  may  be  subdivided  into  re¬ 
quests  for  provisions,  special  program  requirements,  SERVMART 
replenishments,  and  the  largest  subcategory  designated  "OTHER". 
Each  group  is  processed  differently.  Table  5-1  provides  a 
brief  description  of  the  processing  method  for  each. 
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If  keypunch  required,  sent  to  DPD  keypunch,  hatch  processed, 
delated  24  hours  and  lotted  behind  all  IPG  II  and  SP.RVMAKT  j 
Issues.  If  from  mechanized  source,  keypunch  is  bypassed 
and  batch  processing  occurs.  In  either  case,  processing  re-j 
suits  in  co.ninglinfc  with  autodin  IPG  Ills.  ! 


Table 


Requisition  Processing  Overview 
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There  is  a  tertiary  subdivision  of  selected  POE  categories 


that  is  implied  in  the  processing  overviews  in  the  table. 

Namely,  if  the  requisitioner  has  a  mechanized  system  such  as 
SUADPS  (Shipboard  Uniform  Automated  Data  Processing  System) , 
then  the  keypunching  function  need  not  be  performed  at  the 
Supply  Center.  The  mechanization  distinction  must  be  made  for 
all  POE  secondary  subdivisions  except  Special  Programs,  SERVMART, 
and  dry  provisions.  Although  the  number  of  mechanized  customers 
is  a  function  of  ship  operating  schedules  and  will  vary  con¬ 
siderably,  it  is  estimated  that  25-33%  of  all  POE  requisitions 
submitted  to  NSC  San  Diego  are  in  a  mechanized  format.  As  a 
final  comment  on  Table  5-1,  it  must  be  emphasized  that  deviations 
from  the  strict  categorization  portrayed  do  exist.  For  example, 
IPG  II  CASREPTs  can  and  do  quality  as  Bearer  requisitions. 
Nevertheless,  only  the  categories  specified  and  the  mechaniza¬ 
tion  feature  will  be  used  to  identify  requisition  types  in  the 
model . 

B.  QUICK  PIC  AND  BEARERS  (WALK-THROUGHS) 

The  data  base  used  for  the  Appendix  B  demand  calculations 
was  October  1979  through  February  1980.  This  period  was  chosen 
to  correspond  to  the  advent  of  the  QUICK  PIC  program.  Prior 
to  October  1979,  NSC  San  Diego  permitted  walk-throughs  (Bearers) 
on  both  IPG  I  and  II  requisitions.  Each  walk-through  represented 
an  interruption  to  normal  processing  and  a  detrimental  impact 
on  the  response  time  associated  with  the  issues  that  were  sub¬ 
sequently  delayed.  Therefore,  except  in  the  case  of  IPG  II 


CASREPTs,  special  project  codes,  and  designated  types  of  mate¬ 
rial  such  as  gas  cylinders,  walk-throughs  were  restricted  to 
IPG  I  requisitions  and  QUICK  PIC  was  established  to  provide  an 
expedited  response  system  for  IPG  IIs  that  heretofore  had  been 
submitted  as  Bearers.  Requisitions  left  at  designated  drop 
points  are  picked  up  by  an  NSC  driver,  processed  and  sorted 
in  a  special  run,  picked/issued  first  on  the  next  working  day, 
and  staged  at  National  City  for  customer  pickup  at  1400.  There¬ 
for,  a  one  working  day  turnaround  time  applies.  The  program 
appears  to  be  working  extremely  well.  The  average  daily  number 
of  Bearers,  and  thus  the  number  of  routine  processing  inter¬ 
rupts,  have  greatly  decreased.  Table  5-2  shows  the  Bearer 
average  for  each  day  of  the  week  and  the  percentage  of  that  day' 
POE  IPG  I  input  that  the  average  represents. 


DAY  OF 

WEEK 

BEARER 

AVG 

STD  DEVIATION 
OF  BEARER  AVG 

BEARER  AVG  %  OF  POE 
IPG  I  DAILY  AVG 

FROM  APPENDIX  B 

SAT-MONDAY 

134 

75.6 

66% 

TUESDAY 

83 

20.5 

45% 

WEDNESDAY 

76 

27.7 

50% 

THURSDAY 

85 

31.5 

56% 

FRIDAY 

98 

35.3 

54% 

Table  5-2.  Bearer  Statistics 

Using  column  4  of  Table  5-2,  the  average  Bearer  percentage  of 
POE  IPG  Is  across  the  week  then  computes  to  54.2%  with  a 


standard  deviation  of  7.8%. 


The  reference  (e)  Customer  Service  Feeder  Reports  do  not 
provide  a  QUICK  PIC  count  although  the  value  has  been  included 
in  the  Hot  Line  IPG  II  daily  total.  However,  available  reports 
do  indicate  a  QUICK  PIC  average  issue  quantity  of  110  per  day. 
Since  it  can  only  be  assumed  that  QUICK  PIC  faces  the  same  proba¬ 
bility  of  availability  as  other  IPG  II  requisitions,  the  average 
daily  number  of  QUICK  PIC  requisitions  is  projected  at  162  per 
day  based  on  a  68%  gross  availability  rate. 

C.  DEMAND  PROCESS  I  I'JG  PROCEDURES 

As  used  in  this  study,  demand  processing  refers  to  the 
function  of  checking  an  item's  on-hand  asset  position  and  taking 
one  of  the  following  three  actions: 

.  Committing  available  assets  to  satisfy  a  requisition 
.  Placing  a  requisition  "in-process"  based  upon  the  current 
availability  of  assets  with  no  commitment/reduction  of  on-hand 
assets  at  that  time 

.  Referring  the  transaction  based  on  nonavailability  of 
assets.  Special  advice  codes  such  as  "Fill  or  Kill"  that  serve 
to  eliminate  the  referral  will  be  ignored  for  the  purposes  of 
this  report. 

The  demand  processing  procedure  is  performed  by  two  UADPS-SP 
(Uniform  Automated  Data  Processing  System  -  Stock  Point)  pro¬ 
grams.  Both  versions  will  refer  transactions  at  the  time  of 
processing  based  on  nonavailability  of  assets.  The  on-line 
version  is  activated  by  transaction/requisition  input  from 
remote  terminals  and  may  be  used  to  either  commit  assets  and 
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receive  a  corresponding  issue  document  for  immediate  processing 
or  place  transactions  in-process.  The  second  program  is  used 
to  perform  batch  demand  processing,  it  is  run  periodically 
throughout  the  day  and  results  in  either  a  commitment  of 
assets  or  a  referral  (partial  issues  are  ignored)  for  each 
requisition  processed.  The  batch  processing  mode,  as  currently 
used,  can  be  viewed  as  a  procedure  for  placing  issue  document 
images  on  tape  for  further  processing  if  assets  were  available. 

All  IPG  I  requisitions,  both  autodin  and  POE,  are  input 
via  remote  terminals  and  either  processed  to  completion  or 
referred.  Autodin  IPG  II  and  III  requisitions  are  received  on 
tape  six  times  a  day  and  batch  processed  each  time.  The  first 
batch  run  is  scheduled  for  0330  and  the  last  at  2200.  There¬ 
fore,  autodin  IPG  II  and  III  processing  can  be  viewed  as  both 
a  generator  of  referrals  based  on  the  gross  availability  at  the 
time  of  batch  processing  and  an  originator  of  six  tapes  contain¬ 
ing  issue  document  images  that  will  undergo  additional  processing. 

There  are  three  additional  batch  processing  runs  daily. 

QUICK  PIC  requisitions  are  batched  separately  at  0100  and  all 
Provisions  requests  are  processed  at  1800  daily.  These  cate¬ 
gories  are  neither  delayed  by  the  Production  Planning  routine 
nor  subjected  to  the  standard  lotting  process;  they  are  simply 
sorted  by  location  and  issued  the  next  working  day.  The  final 
batch  run  serves  as  a  supplement  to  the  six  autodin  runs  already 
mentioned.  It  must  be  noted  that  while  the  autodin  runs  are 
scheduled  to  accommodate  the  IPG  II  and  III  autodin  input,  any 
available  POE  input  will  also  be  batch  processed  during  the  six 
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runs.  Therefore,  all  POE  input  except  Provisions  and  QUICK 
PIC  will  be  processed  during  one  of  the  seven  aforementioned 
batch  runs.  Of  course,  nonxnechanized  input  can  not  be  batch 
processed  until  it  has  been  keypunched  as  described  in  Chapter 
7. 

The  astute  reader  will  recognize  that  all  the  Table  5-1 
categories  have  now  been  addressed  except  for  the  POE  IPG  II 
requests  from  nonmechanized  customers.  This  category  of  trans¬ 
action  is  put  in-process  from  remote  terminals  during  the  course 
of  the  day  and  no  assets  are  reserved/committed  for  these  demands 
until  approximately  1800  when  the  UADPS-SP  program  that  releases 
in-process  issues  generates  another  tape  containing  issue  docu¬ 
ment  images.  To  illustrate  the  consequences  of  this  procedure, 
it  must  be  noted  that  batch  processing,  which  commits  assets, 
may  allocate  material  to  a  lower  priority  requisition  if  the 
batch  run  is  conducted  after  the  POE  IPG  II  is  put  in-process 
but  before  its  1800  release.  Secondly,  POE  IPG  IIs  put  in- 
process  after  1800  by  the  Customer  Service  second  shift  are 
necessarily  delayed  approximately  24  hours  and  subjected  to 
another  series  of  batch  runs  that  may  commit  available  assets. 

This  factor  becomes  particularly  relevant  when  it  is  realized 
that  placing  POE  IPG  II  requisitions  in-process  is  of  secondary 
importance  with  respect  to  processing  autodin  and  POE  IPG  I 
transactions.  Therefore,  it  may  reasonably  be  assumed  that  many 
of  these  in-process  actions  are  initiated  on  the  second  shift 
and,  at  least  potentially,  accomplished  after  1800.  In  recognition 


of  these  possible  adverse  consequences,  a  rescheduling  of  the 
in-process  release  program  to  a  later  time  (nearer  to  2400) 
is  being  considered.  In  addition,  discussions  currently  being 
held  will  probably  lead  to  revised  demand  processing  batch 
procedures  that  will  function  to  place  some,  and  possibly  all, 
IPG  III  demands  in-process  where,  when  released,  they  will  be 
issued  after  IPG  IIs. 

The  information  provided  thus  far  in  this  chapter  has  been 
presented  to  emphasize  the  complexity  of  requisition  processing 
procedures  and  provide  the  rationale  for  numerous  features 
that  will  be  incorporated  into  the  model.  Prior  to  proceeding 
with  a  discussion  of  the  NSC  demand  data  contained  in  Appendix 
B,  it  is  imperative  to  realize  that  the  various  tapes  contain¬ 
ing  issue  document  images  are  all  run  through  appropriate  local 
Production  Planning/sorting/lotting  programs  beginning  at 
approximately  0300.  The  relevance  of  this  factor  is  that  the 
issue  documents  associated  with  transactions  that  were  either 
batch  processed  or  released  from  in-process  are  not  delivered 
to  the  appropriate  warehouse  until,  at  the  earliest,  0730  the 
next  working  day. 

D.  NSC  SAN  DIEGO  DEMAND  DATA  ANALYSIS 

Appendix  B  contains  daily  requisition  frequency  averages 
for  the  five  month  period  encompassing  October  1979  through 
February  1980.  As  previously  mentioned,  the  beginning  of  this 
period  corresponds  to  the  commencement  of  the  QUICK  PIC  pro¬ 
gram.  Daily  averages  were  computed  from  the  reference  (e) 
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reports  and  include  IPG  I,  II,  and  III  averages  within  both 
the  autodin  and  POE  categories.  Provisions  requisitions  are 
listed  as  a  separate  POE  category  and  are  considered  IPG  III 
requests  despite  the  existence  of  occasional  IPG  II  demands. 

The  data  was  displayed  in  the  Appendix  B  format  to  determine 
whether  similar  IPG  percentages  applied  to  autodin  and  POE  re¬ 
quests.  The  data  illustrates  that  the  IPG  I  percentage  ranged 
from  14.5%  to  21.2%  for  autodin  transactions  and  from  4.7%  to 
6.5%  for  POE  demands.  This  significant  difference  effectively 
ruled  out  any  assumption  that  IPG  percentages  were  consistent 
for  both  major  transaction  categories.  That  factor  and,  per¬ 
haps  more  importantly,  the  extended  portion  of  the  day  for 
which  autodin  arrivals  occur  led  to  the  decision  to  model  the 
arrivals  separately.  Therefore,  Chapter  6  describes  distinct 
arrival  and  transaction  categorization  processes  for  each  type. 

A  cursory  review  of  Appendix  B  indicates  an  excessive  amount 
of  variability  in  the  category  averages.  In  fact,  had  the 
replacements  indicated  in  the  appendix  footnotes  not  been  made, 
the  applicable  standard  deviations  would  have  been  even  higher. 

In  view  of  the  nature  of  the  data,  the  time  between  arrivals 
will  be  assumed  to  be  uniformly  distributed  for  both  autodin 
and  POE  source  networks.  Some  consideration  was  given  to  defining 
gamma  distribution  parameters  that  would  more  accurately  reflect 
the  interarrival  times  implied  by  the  Appendix  B  demand  data. 
However,  the  lack  of  any  definitive  information  relating  input 
levels  to  time  of  day  made  this  approach  significantly  less 
attractive.  If  a  more  detailed  analysis  of  the  requisition 
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arrival  process  is  conducted  in  the  future,  the  model  may 
easily  be  modified  through  the  replacement  of  the  existing 
ACT  (activity)  and  PAR  (parameter)  input  cards  described  in 
Chapter  6. 

Since  a  uniform  time  between  arrivals  implies  that  each 
duration  within  a  specified  interval  is  equally  likely,  the 
maximum  and  minimum  durations  are  the  only  values  specified 
by  Appendix  A  as  necessary  to  define  a  UN  (uniform)  parameter 
set.  Using  Thursday  demand  data  from  Appendix  B  and  assuming 
arrivals  may  occur  over  a  24  hour  period,  the  uniform  dis¬ 
tribution  parameter  set  (max  and  min)  will  be  computed  for 
autodin  arrivals  in  the  following  manner: 

.  An  IPG  percentage  weighted  standard  deviation  will  be 
computed  using  the  formula 

.I  1-§-q—  -■  *  S.  Deviation  IPG  i. 

The  computation  for  Thursday  is  given  by 

(.168x120.62)  +  (.428x445.37)  +  (.404x243.27)  =  309  . 

This  calculation  can  be  considered  to  represent  an  expected 
standard  deviation  across  all  IPGs. 

.  The  maximum  and  minimum  time  between  arrivals  will  then 
be  calculated  as  the  times  associated  with  the  arrival  of  a 
requisition  quantity  two  weighted  standard  deviations  lower 
and  higher  than  the  daily  average.  The  maximum  time  between 
arrivals  would  occur  when  the  number  of  arrivals  was  two  weighted 
standard  deviations  below  the  average;  i.e.,  1829  -  618  =  1211 


arrivals  which  implies  a  0.0198  hour  (24  —  1211)  maximum.  The 
minimum  is  given  by  24  -f-  (1829  +  618)  =  0.0098. 

The  parameter  set  describing  the  POE  arrivals  may  be  defined 
in  a  similar,  but  slightly  more  complex,  manner.  An  expected 
standard  deviation  across  all  Hot  Line  IPG  ■  would  be  computed 
as 


(.06  x  76.47)  +  (.615  x  763.77)  +  (.325  x  339.9)  =  585 

for  Thursday’s  data.  Adding  two  standard  deviations  (1,170) 
to  the  Hot  Line  daily  average  of  2,551  yields  3,721  as  the  num¬ 
ber  of  requisitions  corresponding  to  the  minimum  value  of  the 
uniform  interval  describing  Hot  Line  arrivals.  Likewise,  sub¬ 
tracting  1,170  indicates  that  1,381  demands  define  the  maximum 
interval  point.  However,  a  Hot  Line  interval  does  not  account 
for  all  POE  input;  Special  Program,  provisions,  and  SERVMART 
requests  are  not  included  for  the  following  reasons : 

.  The  reference  (e)  reports  generally  allotted  the  same 
number  of  demands  for  provisions  to  each  day  of  a  given  week/ 
reporting  period.  This  occurred  because  weekly,  vice  daily, 
provisions  counts  were  provided. 

.  Special  Program  demand  submission  patterns  were  necessarily 
very  sporadic  due  primarily  to  the  accumulation  of  requests  for 
specific  programs.  The  existence  of  numerous  "zero  transaction" 
days  and  widely  fluctuating  quantities  made  it  prudent  to  simply 
compute  a  daily  average  of  107  IPG  II  requests  and  590  IPG  III. 

.  The  only  SERVMART  replenishment  count  data  that  was 
readily  available  was  a  255/day  average. 
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To  account  for  these  three  special  categories,  which  will 
immediately  be  extracted  and  separately  identified  in  the 
model,  the  minimum  and  maximum  POE  endpoints  described  above 
must  be  shifted.  Therefore,  the  sum  of  the  daily  averages  for 
Special  Program,  SERVMART,  and  provisions  (specified  by  day) 
requests  must  be  added  to  both  sides  of  the  interval.  Thurs¬ 
day's  uniform  demand  interval  will  then  be  defined  in  the 
following  manner:  [1,381  +  (107  +  590  +  255  +  550),  3721  + 

(107  +  590  +  255  +  550)]  or  [2,883  ,  5,223].  Finally,  the  time 
between  arrivals  associated  with  the  appropriate  requisition 
quantity  is  calculated  by  dividing  each  value  into  8  hours, 
the  time  period  over  which  POE  arrivals  will  occur.  The  resulting 
interval  is  [0.0015,  0.0028]. 

E.  EXCEPTIONS  AND  WAREHOUSE  REFUSALS 

Numerous  unprogrammed  interruptions  to  the  demand  processing 
procedure  may  occur.  Demand  exceptions  and  warehouse  refusals 
are  two  such  delays  that,  when  they  occur,  inhibit  further 
processing  until  manual  corrective  action  has  been  taken.  In 
the  NSC  San  Diego  model,  the  necessary  corrective  action  will 
be  taken  by  the  exception  processing  unit  within  the  Customer 
Service  Division. 

A  demand  exception  occurs  when  a  requisition  fails  one  of 
the  many  validity  checks  made  by  the  demand  processing  program. 

If  the  requisition  is  entered  from  a  remote  terminal,  the  excep¬ 
tion,  if  encountered,  will  kick  out  at  the  remote  terminal  and 
be  processed  immediately.  Using  terminology  that  defines  the 
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modeling  approach,  an  exception  resulting  from  a  remote  trans¬ 
action  input  will-  go  to  tjze  head  of  the  exception  processing 
unit  queue.  Exception  output  from  the  batch  processing  runs 
will  be  routed  to  the  exception  queue  and  processed  in  IPG 
sequence.  QUICK  PIC  exceptions  will  be  processed  together 
at  the  beginning  of  each  work  day.  The  only  data  available 
for  computing  an  exception  rate  was  the  reference  (e)  count 
of  exceptions  received  during  the  five  month  data  base.  There 
were  49,655  exceptions  lodged  against  the  644,013  requisitions 
processed  over  the  same  period. 

Warehouse  refusals  occur  when  insufficient  assets  exist 
in  the  warehouse  to  issue  the  quantity  specified  on  the  issue 
document.  This  situation  represents  a  mismatch  in  the  recorded 
and  actual  on-hand  quantity  and  indicates  a  reconciliation  is 
required.  In  actual  operations  a  warehouse  refusal  and  partial 
issue  will  often  occur  together;  i.e.,  some  assets  were  on-hand 
and  used  to  partially  satisfy  the  customer  request  but  the 
remainder  represents  a  warehouse  refusal  because  the  MSIR  (Master 
Stock  Item  Record)  indicated  the  entire  quantity  was  available. 
However,  the  model  will  not  recognize  partial  issues.  The  occur¬ 
rence  of  a  warehouse  refusal  will  indicate  that  the  entire  quan¬ 
tity  was  NIS  (Not-In-Stock) .  Therefore,  transactions  exiting 
the  processing  stream  as  warehouse  refusals  will  be  routed 
to  the  exception  desk/queue,  processed,  and  removed  from  the 
system.  Actual  subsequent  processing  would  normally  lead  to 
a  referral  based  on  nonavailability  of  assets.  A  1%  warehouse 
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refusal  rate  based  on  a  recent  NSC  San  Diego  Quality  Control 
study  will  be  used. 

It  is  assumed  that  the  exception  total  of  49,655  given  above 
includes  warehouse  refusals  that  must  be  subtracted  before  a 
demand  exception  rate  can  be  estimated.  Since  warehouse  refusal 
rates  refer  to  a  percentage  of  issues  rather  than  requisitions, 
the  1%  rate  will  have  to  be  applied  to  the  number  of  issues 
projected  from  a  644,013  transaction  input.  Assuming  a  gross 
availability  rate  of  65%,  the  number  of  warehouse  refusals  over 
the  five  month  data  base  is  estimated  to  be  4,186  (0.01  ><0.65 
x  644,013).  The  exception  total  must  be  further  reduced  by  an 
estimated  250  per  week  input  of  nonstandard  material  exceptions 
that  will  not  apply  in  this  model.  Therefore,  an  additional 
5,500  (250  x 22)  exceptions  will  be  excluded  from  the  exception 
total  and  it  will  be  assumed  that  the  demand  exception  total 
over  the  five  month  period  was  39,969  (49,655  -  (4,186  +  5,500)). 
The  resulting  estimated  demand  exception  rate  of  6.2%  (39,969 
~  644,013)  will  be  used  in  the  model. 

SERVMART  replenishment  requisitions  are  generated  locally 
using  the  automated  EPOS  system.  Therefore,  under  the  assumption 
that  demand  exceptions  seldom  occur  when  using  this  automated 
procedure,  SERVMART  demands  will  not  be  tested  for  demand  excep¬ 
tions.  Similarly,  provisions  requests  are  arbitrarily  excluded 
from  exception  testing  in  recognition  of  the  limited  number  of 
fields  that  must  be  entered  on  the  prepunched  requisitions  by 
the  customer  and  keypunched  in  DPD. 
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An  appropriate  analysis  of  the  demand  exception  rate  would 
require,  at  the  very  least,  exhaustive  research  of  the  UADPS- 
SP  Program  Processing  statistics  exception  data  and ’ represents 
an  effort  that  is  beyond  the  scope  of  this  project.  Therefore, 
the  relatively  simple  computation  presented  will  have  to  suffice 
until  a  more  accurate  assessment  can  be  made.  Although  a  more 
recent  gross  availability  rate  of  68%  is  used  later  in  the 
model,  it  was  not  considered  necessary  to  change  the  demand 
exception  computation,  which  was  based  on  the  lower  (65%)  availa¬ 
bility  value.  Regardless  of  the  value  used,  65%  or  68%,  an 
exception  rate  of  approximately  6%  is  intuitively  too  high 
but,  if  nevertheless  accurate,  certainly  worthy  of  management 
attention. 

F.  MODELING  CONSIDERATIONS 

Prior  to  beginning  the  actual  modeling  of  the  requisition 
processing  components,  a  brief  discussion  of  the  modeling 
approach  is  advisable.  The  three  principle  factors  influencing 
the  modeling  approach  are  the  desire  to  gradually  and  system¬ 
atically  incorporate  complexity,  the  difficulties  associated 
with  modeling  the  timing  of  requisition  processing,  and  the 
existence  of  a  maximum  node  constraint  of  100. 

Despite  possessing  many  features  that  simplify  the  modeling 
process,  Q-GERT  appears  to  lack  a  programmed  approach  for  accu¬ 
mulating  then  releasing  all  transactions  after  a  specified  time 
period.  Modeling  activities  like  messenger  services,  the 
accumulation  of  requisitions  prior  to  a  scheduled  batch  run. 
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and  the  filling  of  accumulator  lines  before  releasing  material 
to  packing  all  depend  on  this  principle  and  are  necessary  to 
approximate  reality  in  the  model.  Therefore,  the  modeling  of 
such  events  will  have  to  be  accomplished  with  FORTRAN  program 
inserts.  The  expanded  modeling  capability  that  can  be  realized 
through  the  use  of  these  inserts  is  one  of  the  most  impressive 
features  of  Q-GERT.  Existing  Q-GERT  subprograms  can  be  accessed 
by  the  user  defined  FORTRAN  segment.  Chapter  7  of  reference 
(a)  describes  the  use  of  program  inserts  and  illustrates  the 
great  degree  of  flexibility  afforded  the  modeler  by  this  feature. 
However,  since  a  stated  objective  of  this  project  is  to  intro¬ 
duce  and/or  use  the  maximum  number  of  pre-def ined  Q-GERT  concepts , 
the  use  of  program  inserts  will  be  limited  to  situations  that 
can  not  be  modeled  otherwise. 

The  timing  of  the  model  refers  not  only  to  the  scheduling 
of  messengers  and  batch  processing  runs,  but  also  the  switching 
of  shifts,  days,  and  weeks.  Since  the  demand  pattern  changes 
from  day  to  day,  the  arrival  rate  will  differ  each  day.  There¬ 
fore,  a  switching  network  will  be  developed  to  periodically 
replace  the  transaction  source  network.  However,  the  IPG  I 
through  III  percentages  for  autodin  and  POE  will  not  be  changed 
on  a  daily  basis.  Six  simple  weekly  averages  taken  from  Appendix 
B  will  be  used  to  define  the  IPG  percentages.  This  step  will 
minimize  the  number  of  network  modifications  that  must  be  made 
when  the  day  of  the  week  changes  without  appreciably  degrading 
the  model  validity.  Due  to  the  complexity  of  timing  the  model. 
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a  chapter  will  be  devoted  to  the  subject  and  presented  after 
the  model  has  been  completed  in  a  "free-flow"  form. 

The  100  node  limitation  and  existing  time  constraints  pre¬ 
sent  insurmountable  obstacles  to  both  model  validation  and  the 
generation  of  representative  simulation  output.  Validation  on 
a  piecewise  basis  could  conceivably  be  accomplished  but,  as 
emphasized  in  the  Introduction,  there  is  a  time  constraint 
associated  with  the  completion  of  this  segment  of  an  unavoidable 
two-phased  study.  Given  this  time  limitation,  the  validation 
of  the  model,  whether  conducted  in  a  piecewise  fashion  or  through 
the  analysis  of  initial  full  model  runs,  will  have  to  be  under¬ 
taken  during  the  second  phase.  Network  segments  requiring  exten¬ 
sive  analysis  during  the  validation  process  are  emphasized 
throughout  the  remaining  chapters  and  reiterated  in  the  Chapter 
11  summary.  Since  the  Q-GERT  cards  corresponding  to  the  model 
developed  in  Chapters  6  through  10  were  created,  an  attempt  was 
made  to  identify  a  convenient  network  segment  containing  less 
than  100  nodes  that  could  be  run  independently.  Due  to  the  com¬ 
plex  relationship  between  the  Chapter  11  disjoint  timing  network 
and  the  remaining  operationally  dependent  segments,  a  represen¬ 
tative  independent  model  could  not  be  readily  identified. 
Nevertheless,  numerous  examples  of  the  standard  Q-GERT  output 
that  would  be  generated  by  simulations  on  a  model  segment  are 
illustrated  in  conjunction  with  the  sample  problems  presented 
in  reference  (a) . 


VI.  MODELING  THE  ARRIVAL  AND  CATEGORIZATION  OF  REQUISITIONS 


A.  ATTRIBUTE  ASSIGNMENT 

Requisitions  arrive  at  the  Supply  Center  as  a  readily  recog¬ 
nizable  member  of  one  of  the  categories  discussed  in  Chapter  5. 
Therefore,  the  arrival  process  in  the  model  will  include  not 
only  the  generation  of  demands,  but  also  the  designation  of  a 
transaction  to  a  category  through  the  attribute  assignment 
feature  of  Q-GERT.  Figure  6-1  shows  the  symbology  necessary 
to  indicate  the  assignment  of  a  single  attribute  at  a  node. 


Attribute  number 

Parameter  set  or  constant 
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Figure  6-1.  Statistics  Node  Used  for  Attribute  Assignment 

Attribute  assignment  information  is  always  placed  in  the  three 
partitions  directly  to  the  left  of  the  node  number.  The  attri¬ 
bute  number  affected  is  at  the  far  left  and  the  method  of  assign¬ 
ing  a  value  to  the  indicated  attribute  is  displayed  in  the  re¬ 
maining  two  partitions.  Figure  6-1  illustrates  the  case  where 
a  value  from  a  normal  distribution  described  by  parameter  set 
1  is  being  assigned  to  attribute  1  of  each  transaction  passing 
through  the  node.  Although  a  statistics  node  is  used  in  the 
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example,  attribute (s)  may  be  assigned  at  any  node  type  tuat 
has  been  presented.  However,  at  each  node  where  an  attribute 
assignment  occurs,  a  VAS  (Value  Assignment)  card  must  be  pre¬ 
pared  in  accordance  with  reference  (a)  instructions.  Any  of 
the  distribution  types  listed  in  Appendix  A  except  AT  may  be 
used  to  define  an  attribute  assignment. 

Figure  6-2  is  provided  to  illustrate  the  procedure  to 
multiple  attribute  assignment  and  introduce  an  additional 
attribute  assignment  technique  not  given  in  Appendix  A. 


Figure  6-2.  Multiple  Attribute  Assignment  at  a  Q-Node 

Attribute  1  is  assigned  a  constant  value  of  1.  Attribute  2 
is  first  being  assigned  a  value  from  a  normal  distribution  des¬ 
cribed  in  parameter  set  1  and  is  then  being  changed  through  the 
addition  of  a  value  taken  from  the  uniform  distribution  described 
in  parameter  set  2.  Since  the  time  to  perform  activity  7  is 
defined  as  the  value  of  attribute  2,  the  service  time  associated 
with  transactions  taken  from  Q-node  6  is  the  sum  of  samples 
from  a  uniform  and  normal  distribution.  If  the  initial  attri¬ 
bute  2  value  assignment  had  occurred  earlier  in  the  network, 
only  the  2+  row  would  have  been  required  to  change  the  value. 
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The  bottom  value  assignment  to  attribute  3  is  the  incremental 
function.  It  indicates  that  attribute  3  of  the  transactions 
leaving  the  Q-node  should  be  sequentially  numbered  with  the 
first  transaction  being  numbered  1.  It  is  not  necessary  to 
start  with  1.  Any  negative  or  positive  number  is  an  acceptable 
starting  point;  each  successive  transaction  will  be  assigned 
an  attribute  3  value  that  is  one  unit  more  positive  than  the 
value  assigned  to  the  previous  transaction. 

The  model  will  primarily  use  attribute  assignments  of  the 
CO  variety.  Attributes  1-3  will  be  assigned  constant  values 
to  represent  the  following  requisition  characteristics: 

.  Attribute  1  is  the  IPG  indicator  with  possible  values 
of  1,  2,  and  3  representing  IPG  I,  II,  and  III,  respectively. 

.  Attribute  2  is  the  keypunch  service  time  taken  from 
Appendix  C.  It  will  be  assigned  one  of  the  following  values: 

. .  0  mechanized  input 
..  0.0032  for  provisions  transactions 
..  0.0067  for  Special  Programs  requisitions 
..  0.0Q71  for  all  other  nonmechanized  transactions 
Although  constant  keypunch  service  times  are  used  in  the  model. 
Appendix  C  provides  sufficient  provisions  and  DD  1348  data  to 
compute  a  relatively  good  estimate  of  keypunch  variability. 

.  Attribute  3  will  be  used  to  establish  ranking  and  pro¬ 
cessing  priorities  in  the  model  and  may  be  assigned  any  of 
the  following  values: 

. .  0  -  Warehouse  Refusal 
. .  1  -  Bearer  Requisition 
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.  .  2  -  IPG  I  (autodin  or  POE) 

. .  3  -  QUICK  PIC 

. .  4  -  IPG  II  (autodin  or  Table  5-1  Other  Category) 

. .  5  -  IPG  III  (autodin  or  Table  5-1  Other  Category) 

. .  6  -  Not  used  (originally  reserved  for  Special  Pro¬ 

gram  requisitions,  but  not  needed) 

.  .  7  -  Provisions 

. .  8  -  SERVMART  replenishments 

B.  CONDITIONAL  BRANCHING 

The  only  branching  techniques  discussed  thus  far  have  been 
deterministic  and  probabilistic.  In  order  to  describe  the 
routing  of  transactions  based  on  attribute  value,  two  additional 
forms  of  branching  designated  conditional-take-all  and  condi¬ 
tional-take-first  must  be  introduced.  Figure  6-3A  illustrates 
the  former  type  and  6-3B  the  latter. 


Figure  6-3A.  Conditional-Take-  Figure  6-3B.  Conditional-Take- 

All  Branching  First-Branching 

Each  transaction  routed  through  node  5  above  will  be  forwarded 
along  every  exiting  branch  for  which  the  specified  condition  is 
met.  For  example,  using  the  model  attribute  assignments  previously 
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presented,  a  Bearer  mechanized  requisition  arriving  at  node  5 
would  lead  to  a  duplicate  of  that  transaction  being  routed 
along  all  three  branches.  On  the  other  hand,  the  arrival  of  a 
POE  IPG  III  nonmechanized  transaction  would  lead  to  an  error 
message  since  none  of  the  conditions  would  be  met;  each  incoming 
transaction  must  satisfy  at  least  one  of  the  specified  condi¬ 
tions  for  both  forms  of  conditional  branching  illustrated  above. 
The  conditional-take-all  method  will  not  be  used  often  in  the 
model.  However,  it  is  presented  to  illustrate  its  potential 
value  to  the  modeler. 

The  conditional-take-first  branching  shown  in  Figure  6-3B 
will  play  a  major  role  in  the  requisition  processing  model. 

In  this  form  of  branching,  the  order  in  which  the  conditions 
are  to  be  evaluated  will  be  specified  and  the  transaction  will 
be  routed  along  the  first  branch  for  which  the  condition  is 
satisfied;  no  further  conditions  will  be  evaluated.  Recall 
that  attribute  2  was  the  keypunch  service  time  and  was  set  to 
either  0  (mechanized)  or  the  appropriate  service  time.  After 
ensuring  that  attribute  2  is  set  for  every  transaction  arriving 
at  node  6  above,  the  simple  branching  illustrated  can  be  used 
to  route  transactions  to  either  keypunch  (A2  ^0)  or  DPD  if 
already  keypunched  (A2  =  0) . 

Conditional  branching  can  be  used  at  all  nodes  discussed 
except  Q-nodes  where  only  probabilistic  or  deterministic  branch¬ 
ing  is  permissable.  Finally,  branching  based  on  specific 
attribute  values  is  only  one  of  many  conditions  that  can  be  used 
for  the  routing  decision.  Branching  can  be  based  on  numerous 
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other  factors  such  as  current  simulation  time,  the  relationship 
of  one  attribute  value  to  another,  and  the  status  (released  or 
not)  of  a  specified  node.  These  conditions  are  listed  on  page 
146  of  reference  (a) . 

C.  THE  AUTODIN  ARRIVAL  AND  CATEGORIZATION  PROCESS 

It  was  noted  in  Chapter  5  that  the  autodin  arrival  process 
was  significantly  different  from  its  POE  counterpart  with  regard 
to  both  the  time  over  which  arrivals  occur  and  the  IPG  categori¬ 
zation  percentages.  Therefore,  it  was  concluded  that  separate 
arrivals  must  be  modeled  for  autodin  and  POE  with  both  display¬ 
ing  a  uniform  time  between  arrivals  due  to  large  variations  in 
the  demand  data.  Figure  6-4  is  the  Q-GERT  representation  of 
the  autodin  arrival  and  requisition  categorization  process  for 
one  day1 s  demand  at  NSC  San  Diego.  Note  that  node  1  is  not  a 
source  node  although  it  is  being  used  to  generate  and  mark 
transactions  in  a  manner  similar  to  the  Figure  2-4  source  node. 
When  preparing  a  Q-GERT  input  card,  node  1  would  be  designated 
a  regular  node  with  a  mark  time  being  assigned.  The  absence  of 
the  — w*  indicator  on  the  input  side  and  the  requirement  for 
1  transaction  to  provide  the  initial  release  indicate  the 
source  node  preceeds  node  1  in  the  network.  In  fact,  the  source 
node  will  be  part  of  the  timing  network  referenced  in  the  rec¬ 
tangle  preceding  node  1.  This  network,  which  will  not  only 
time  the  daily  input  but  will  also  shift  the  day  of  the  week, 
will  be  covered  in  a  later  chapter.  Prior  to  introduction  of 
the  timing  network,  the  transaction  flow  in  the  model  is  con¬ 
strained  only  by  the  delays  indicated  on  the  branches  and  time 
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spent  at  Q-nodes  awaiting  either  service  or  a  timing  pulse.  If 
no  delay  is  indicated  on  a  branch,  the  default  value  of  (CO,0) 
applies.  Note  that  the  transaction  from  the  timing  network 
to  node  1  is  assigned  a  delay  from  the  same  interarrival  dis¬ 
tribution  as  activity  [T]  ;  this  timing  pulse,  which  activates 
node  1  for  the  specified  24  hour  period,  also  represents  the 
first  requisition  arrival  of  the  day  since  it  is  routed  along 
both  branches  (deterministic  branching)  leaving  node  1. 


Thursday  demand  dec a 
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Figure  6-4.  Autodin  Arrival  and  Categorization  Process 

Figure  6-4  illustrates  the  simplicity  of  the  autodin  arrival 
and  categorization  process.  Since  the  requisitions  are  all 
mechanized,  an  attribute  2  keypunch  service  time  of  zero  is 
immediately  assigned  to  each  demand  generated.  The  attribute 
4=0  assignment  will  be  discussed  later.  Node  2  provides 
probabilisitc  branching  proportional  to  the  simple  weekly 


average  IPG  percentages.  At  nodes  3,  4,  and  5  each  transac¬ 
tion  is  assigned  an  attribute  1  value  equal  to  its  IPG.  In 
addition,  attribute  3  values  of  2,  4,  and  5  are  assigned  to 
IPGs  I,  II,  and  III,  respectively,  to  establish  future  pro¬ 
cessing  priorities.  Modeling  nodes  3,  4,  and  5  as  regular 
nodes  is  only  appropriate  for  describing  the  immediate  release 
of  incoming  transactions  to  DPD  or  Customer  Services.  In 
actuality,  arriving  transactions  must  await  the  appearance  of  . 
a  scheduled  messenger.  Therefore,  Figure  6-5  represents  a 
more  realistic  model  of  autodin  processing  procedures  and  also 
permits  the  introduction  of  two  additional  Q-GERT  concepts, 
the  match  node  and  user  functions.  The  Figure  6-4  value  assign¬ 
ment  of  attribute  4  =  0  at  node  1  was  made  to  facilitate  the 
matching  process. 

Chapter  5  mentioned  the  absence  of  a  well  defined  Q-GERT 
concept  to  model  a  scheduled  messenger  service.  The  match 
nodes  used  in  Figure  6-5,  nodes  7  and  10,  and  the  network 
associated  with  them  illustrate  one  possible  messenger  modeling 
scheme . 

The  match  node  functions  to  delay  the  removal  of  a  transac¬ 
tion  from  a  Q-node  until  a  transaction  with  a  matching  selected 
attribute  value  arrives  at  another  Q-node.  Q-node  5,  which 
was  shown  as  a  regular  node  on  Figure  6-4,  contains  IPG  I  auto¬ 
din  requisitions  with  an  attribute  4=0  assignment  from  node  1. 
These  transactions  are  to  be  forwarded  to  Customer  services  for 
processing.  However,  match  node  7  functions  to  delay  the  rout¬ 
ing  until  a  transaction  with  attribute  4=0  arrives  at  Q-node  8. 
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Figure  6-5.  Revised  Autodin  Arrival  and  Categorization  Process 


When  a  match  does  occur,  one  transaction  will  depart  each  Q- 
node  and  be  forwarded  to  nodes  specified  on  the  Q-GERT  card 
describing  the  match  node.  The  nodes  on  the  output  side  of 
the  match  node  may  be  any  type  previously  discussed.  Only 
Q-nodes,  as  many  as  five,  may  comprise  the  input  side  of  a 
match  node.  The  dashed  lines  on  both  sides  of  the  node  indicate 
that  they  are  not  activities  and  no  ACT  cards  are  required; 

Q-node  cards  will  reference  the  match  nodes  and  the  match  node 
card  specifies  the  Q-node/node  routing  that  will  occur  upon 
matching . 

It  would  be  permissible  to  release  transactions  from  Q-node 
5  one  at  a  time  based  upon  triggers  sent  to  match  node  7  from 
a  Q-node  in  the  timing  network.  Of  course,  the  arriving  matching 
transaction  must  have  an  attribute  4  =  0  and  be  routed  to  node 
9  by  the  match  node.  In  that  case,  the  timing  pulses  would 
simply  depart  the  network  at  node  9  with  no  further  routing 
and  one  requisition  in  Q-node  5  would  be  routed  each  time. 
However,  the  situation  that  must  be  modeled  is  a  messenger 
service  with  a  scheduled  departure  of  all  transactions  in  Q- 
node  5.  Therefore,  upon  receiving  a  transaction  having  attri¬ 
bute  4=0  from  the  timing  network,  the  nodes  83,  8,  7,  9,  and 
85  logic  will  effect  the  desired  instantaneous  transfer  of 
all  requisitions  in  Q-node  5. 

The  messenger  modeled  by  the  match  node  7  network  is  assigned 
to  Customer  Services.  His  route  includes  numerous  stops  that 
will  not  be  considered  in  the  model.  His  arrival  at  DPD  in 
Figure  6-5,  the  Broadway  warehouse,  and  two  Customer  Services 
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queues  will  be  simulated.  Four  complete  rounds  will  be  made 
during  an  eight  hour  working  day  beginning  at  0700.  The 
modeled  route  is  not  identical  to  the  sequence  of  stops  actually 
made.  However,  the  requisition  flow  and  subsequent  delays 
that  are  initiated  upon  his  arrival  are  realistic.  Each  com¬ 
plete  round  will  be  initiated  by  a  timing  network  pulse  arriv¬ 
ing  at  node  83  on  Figure  6-5.  The  completion  of  one  round  could 
be  used  to  initiate  the  beginning  of  thenext  by  using  a  timed 
modification  of  mode  83  to  inhibit  messenger  activity  after 
the  working  day  is  over.  However,  the  required  nodal  modifica¬ 
tion,  a  concept  that  will  be  introduced  in  Chapter  7,  would 
represent  an  unacceptable,  and  avoidable,  level  of  complexity 
at  this  stage  of  model  development. 

The  transaction  arriving  at  node  83  to  initiate  a  messenger 
run  is  immediately  assigned  the  indicated  attribute  3  and  4 
values.  Attribute  4  is  assigned  a  constant  zero  value  to 
force  a  match  at  node  7  bf  Q-node  5  has  autodin  IPG  I  requisi¬ 
tions  for  the  messenger  to  take  to  Customer  Services .  The 
attribute  3  value  assignment  made  by  UF  (User  Function)  5,  a 
FORTRAN  program  insert  shown  in  Appendix  D,  will  be  the  nega¬ 
tive  of  the  number  of  requisitions  in  Q-node  5.  If  Q-node  5 
is  empty,  attribute  3  (AT  3)  will  be  equal  to  zero,  the  upper 
conditional-take-first  branch  will  be  taken,  and  the  transaction 
representing  the  messenger  will  bypass  the  matching  process 
and  be  routed  directly  to  node  85.  The  delay  shown  on  the  branch 
leaving  node  85  represents  messenger  travel  time  to  Customer 
Services  where  node  86' is  located.  Therefore,  no  attempt  will 
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be  made  to  route  autodin  IPG  I  requisitions  from  Q-node  5  to 
regular  node  84  (via  match  node  7)  when  there  are  no  transac¬ 
tions  to  process . 

If  Q-node  5  does  contain  requisitions,  attribute  3  of  the 
transaction  leaving  node  83  will  be  a  negative  number  with  an 
absolute  value  equal  to  the  number  of  autodin  IPG  Is  waiting 
to  be  routed.  The  "messenger"  will  then  be  sent  to  Q-node  8 
where  his  attribute  4  value  will  be  compared  to  the  attribute 
4  value  of  the  first  requisition  in  Q-node  5.  Since  they  are 
both  zero,  a  match  will  occur  and  a  transaction  will  depart 
each  Q-node.  The  requisition  leaving  Q-node  5  will  be  routed 
to  node  84  and  then  delayed  0.5  hours  before  reaching  the  edit 
queue  (Q-node  33)  in  Customer  Services.  Upon  leaving  Q-node 
8  the  messenger  transaction  will  have  its  attribute  3  value 
increased  by  a  constant  1  and  routed  to  node  9  via  the  match 
node.  It  is  important  to  note  that  the  match  occurred  before 
the  value  assignment  that  changed  attribute  3  was  made;  attri¬ 
bute  assignments  occur  after  a  node  is  released,  but  before 
conditional  branching  criteria  are  evaluated.  Therefore,  the 
messenger  could  not  have  been  assigned  an  attribute  4  value 
of  zero  at  Q-node  <8  and  ensure  an  attribute  4  match  with  Q-node 
5;  the  attribute  4  value  assignment  of  zero  needed  for  the 
match  could  not  be  made  until  Q-node  8  was  released  and,  para¬ 
doxically,  a  release  of  node  8  could  not  occur  until  the  match 
on  attribute  4  was  made.  Therefore,  the  match  was  ensured  at 
node  83  prior  to  the  transaction's  arrival  at  Q-node  8. 
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When  the  conditional  branching  at  node  9  is  encountered 
for  the  first  time,  the  absolute  value  of  the  messenger  attri¬ 
bute  3  assignment  is  one  less  than  the  original  number  of 
transactions  in  Q-node  5.  However,  since  one  requisition  de¬ 
parted  Q-node  5  at  the  initial  match,  the  attribute  3  value 
of  the  messenger  represents  the  number  of  requisitions  remain¬ 
ing  in  Q-node  5  at  the  time  of  the  branching  from  node  9. 
Therefore,  when  Q-node  5  is  empty,  the  messenger  attribute  3 
value  will  be  zero  at  node  9  and  the  branch  to  node  85  will  be 
taken.  If  additional  autodin  IPG  Is  remain  in  Q-node  5,  the 
messenger  attribute  3  value  will  represent  that  quantity  and 
the  lower  node  9  branch  will  be  taken.  The  routing  back  to 
Q-node  8  has  no  delay  associated  with  it  and  the  arriving  trans¬ 
action  has  AT  4  =  0.  Therefore,  another  match  occurs,  one  more 
autodin  IPG  I  departs  Q-node  5,  and  the  messenger  transaction ' s 
AT  3  value  is  decremented  (in  absolute  value)  by  one  unit 
before  the  node  9  branching  conditions  are  evaluated.  The 
lower  branch  from  node  9  will  be  taken  until  Q-node  5  is  empty. 
No  simulation  time  is  consumed  by  the  repeated  branchings  back 
to  Q-node  8  and,  in  effect,  the  autodin  IPG  Is  are  all  removed 
(forwarded  to  Customer  Services  via  node  84)  at  the  same  time. 

The  messenger  process  was  presented  in  detail  to  minimize 
the  explanation  needed  for  similar  transfer  networks  appearing 
throughout  the  model.  The  Figure  6-5  network  consisting  of 
nodes  81,  82,  6,  10,  11,  and  12  is  logically  equivalent  and 
functions  to  route  all  autodin  and  POE  transactions  in  Q-node 
6  to  a  scheduled  DPD  batch  processing  run  initiated  by  the 


64 


arrival  of  a  transaction  at  node  81.  The  batch  processing 
procedure  is  addressed  in  Chapter  8.  Note  that  the  transaction 
leaving  node  82  is  lost  to  the  system  vice  routed  in  a  manner 
similar  to  the  messenger  leaving  node  85.  This  approach  is 
permissable  and  node  82  must  be  included  to  permit  the  branch¬ 
ing  evaluation  at  nodes  81  and  12  prior  to  destroying  the 
transaction;  i.e.,  the  upper  branches  of  nodes  81  and  12  could 
not  have  been  used  to  destroy  the  transaction  through  omitting 
a  node  to  receive  the  transaction.  The  branch  description 
provided  in  the  ACT  (activity)  input  card  specifies  the  branch¬ 
ing  condition  to  be  evaluated  and  an  ACT  card  must  contain  a 
start  and  end  node.  On  the  other  hand,  the  transaction  leaving 
node  85  is  routed  to  node  86  instead  of  being  lost  to  the  sys¬ 
tem.  Consequently,  node  85  is  not  actually  needed.  The  upper 
branches  from  nodes  83  and  9  could  have  been  assigned  identical 
messenger  delays  and  routed  directly  to  node  86. 

Three  additional  points  must  be  made  regarding  Figure  6-5. 
First,  Q-node  6  was  added  to  the  Figure  6-4  network  to  queue 
IPG  II  and  III  autodin  and  POE  demands  for  batch  processing. 
This  was  done  not  only  to  comply  with  the  requirement  that  only 
Q-nodes  may  serve  as  match  node  input,  but  also  to  model  trans¬ 
action  waiting  times;  regular  nodes  such  as  nodes  3  and  4  can 
not  lead  to  a  delay  unless  transactions  are  being  accumulated 
as  described  in  Chapter  4.  Secondly,  although  a  match  node 
may  have  multiple  Q-nodes  on  its  input  side,  one  match  node 
could  not  be  used  to  empty  Q-nodes  5  and  6;  the  circuitry 
associated  with  each  Q-node  represents  a  different  "messenger 


system"  with  a  different  schedule  and,  more  importantly,  the 
required  matching  transaction  from  every  input  Q-node  would 
cease  to  exist  when  the  Q-node  having  the  least  initial  number 
of  requisitions  was  empty.  Finally,  all  the  Q-nodes  on  Figure 
6-5  rank  transactions  on  a  FIFO  basis.  Q-node  6  indicates  this 
fact.  The  other  Q-nodes  are  assigned  no  ranking  designator 
to  indicate  that  the  default  procedure,  which  is  also  FIFO,  is 
being  used. 

It  should  be  apparent  that  match  nodes  can  be  best  used  to 
model  situations  like  programmed  delays  prior  to  routing  of 
individual  transactions  and  awaiting  the  arrival  of  several 
(up  to  five)  dissimilar  components  before  commencing  an  assembly 
operation.  The  Figure  6-5  messenger  application  is  cumbersome 
at  best.  It  represents  a  considerable  investment  in  nodes  to 
provide  the  additional  network  logic  to  effect  the  transfer 
and  model  messenger  travel  time.  Since  the  dashed  lines  to 
and  from  a  match  node  do  not  represent  activities ,  they  can  not 
be  modeled  as  a  delay.  However,  the  only  available  alternaitve 
is  a  variable  resource  allocation  technique  that  does  not  repre¬ 
sent  a  significant  savings  in  the  number  of  nodes  consumed. 
Resources  will  be  introduced  in  Chapter  7  and  the  use  of  a 
variable  resource  scheme  to  model  a  timed  release  of  numerous 
transactions  will  be  introduced  in  Chapter  8. 

Finally,  note  that  there  are  no  post-arrival  delays  assigned 
to  the  requisitions  during  the  categorization  process  leading 
to  arrival  in  Q-nodes  5  and  6.  Demand  categories  are  recogniza¬ 
ble  upon  arrival  and  therefore  require  no  categorization  time. 
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In  addition,  the  sequential  activity  numbers  assigned  to  each 
branch  on  Figure  6-4  are  omitted  on  6-5.  Branches  that  do 
not  contain  activities  of  interest  such  as  interarrival  dis¬ 
tributions  and  service  functions  referenced  on  output  will 
not  be  assigned  a  specific  number  and  descriptive  label. 
Therefore,  only  the  interarrival  branch  on  node  1  is  numbered. 
The  remaining  branches  will  be  automatically  numbered  by  the 
Q-GERT  Analysis  Program. 

Figure  6-5  represents  events  occurring  in  DPD.  Autodin 
tape  input  is  actually  received  in  the  communications  center 
and  routed  to  DPD  by  messenger  for  segregation  of  IPG  Is  and 
batch  processing  of  IPG  II  and  III  demands.  It  was  not  con¬ 
sidered  essential  to  model  the  communications  center  activity. 
The  batch  autodin  processing  is  contingent  upon  the  arrival 
of  input  that  may  have  been  waiting  in  the  communication  center; 
on  Figure  6-5,  a  proportional  delay  will  be  encountered  in 
Q-nodes  5  and  6. 

The  input  to  Q-node  6  shown  arriving  from  Figure  7-7  nodes 
100,  105,  and  111  consists  of  mechanized  POE  input  including 
SERVMART ,  keypunched  IPH  III  DD  1348s,  and  Special  Program 
requisitions.  The  processing  of  these  categories  is  discussed 
in  Chapter  7.  Their  inclusion  in  Q-node  6  models  the  concurrent 
processing  of  autodin  and  available  POE  input. 

D.  THE  POE  ARRIVAL  AND  CATEGORIZATION  PROCESS 

Figure  6-6  depicts  the  POE  arrival  and  categorization  pro¬ 
cess.  Although  the  analogous  autodin  process  was  modeled  solely 
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on  IPG  considerations,  the  POE  model  must  account  for  many 
additional  subcategories.  Aside  from  the  addition  of  cate¬ 
gories,  the  model  does  not  represent  a  significant  increase 
in  complexity. 

The  POE  interarrival  process  was  presented  in  Chapter  5 
and  need  not  be  discussed  further.  Demands  arriving  at  node 
14  are  probabilistically  routed  in  relation  to  the  specified 
category's  percentage  of  Thursday  demand..  SERVMART  replenish¬ 
ment  requisitions,  averaging  255  per  day,  represent  6.3%  of 
total  daily  demand  of  4,053  (2551  Hot  Line,  550  Provisions, 

107  Special  Programs  IPH  II,  590  Special  Programs  IPH  III, 
and  255  SERVMART).  Provisions  represent  13.6%  and  Special  Pro¬ 
gram  IPG  II  and  III  demands  account  for  2.6%  and  14.5%,  respec¬ 
tively.  That  consumes  37%  of  the  daily  average  and  leaves  63% 
to  be  distributed  among  the  Hot  Line  POE  IPGs.  The  Hot  Line 
weekly  average  percentages  by  IPG  are  5.64%  (I),  57.14%  (II), 
and  37.22%  (III).  These  values  are  indicated  on  the  applicable 
branches  leaving  node  22.  As  mentioned,  this  apportionment 
applies  to  the  63%  of  the  input  leaving  node  14.  The  mechani¬ 
zation  split  of  70%  nonmechanized  and  30%  mechanized  and  the 
assignment  of  keypunch  service  times  occurs  at  nodes  15,  20, 
and  21  before  the  Hot  Line  IPG  branching  at  node  22.  This 
sequencing  models  the  assumption  that  the  mechanization  percen¬ 
tage  is  constant  across  all  IPGs. 

All  categories  except  Hot  Line  simply  have  the  appropriate 
attribute  values  assigned  at  regular  nodes  16  through  19  and 
are  forwarded  to  Q-node  25  to  await  the  messenger  modeled  by 
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Figure  6-6.  POE  Arrival 


the  nodes  28,  29,  30,  86,  and  87  logic.  Special  Program  de¬ 
mands,  being  identifiable  by  their  keypunch  value  assignment 
of  0.0067,  were  not  assigned  distinct  attribute  3  values  at 
nodes  18  and  19;  the  values  assigned  correspond  to  the  autodin 
IPG  II  and  III  attribute  3  designators  shown  on  Figure  6-5. 

All  Hot  Line  IPG  Ills  and  mechanized  IPG  IIs  are  also  shown 
going  directly  to  Q-node  25.  This  branching  deviates  from 
reality  in  the  sense  that  all  POE  Hot  Line  input  is  counted 
and  edited  in  Customer  Services.  However,  mechanized  IPG  IIs 
and  all  IPG  Ills  usually  arrive  in  batches  and  are  necessarily 
afforded  an  extremely  cursory  edit  of  a  duration  that  is 
insignificant  with  respect  to  time  awaiting  the  messenger. 
Therefore,  these  requisition  categories  will  bypass  the  routing 
through  Customer  Services  editing  before  arriving  at  Q-node  25. 
To  compensate  for  the  reduced  edit  queue  input,  the  number 
of  servers  performing  the  edit  function,  which  was  specified 
as  2  in  the  reference  (b)  study,  will  be  limited  to  1. 

Hot  Line  IPG  IIs  are  proportioned  into  the  QUICK  PIC  (9%) 
and  Table  5-1  Other  (91%)  categories  at  node  23.  The  QUICK 
PIC  percentage  was  computed  using  an  average  daily  input  of 
162  and  dividing  this  value  by  the  average  Hot  Line  IPG  II 
input  over  the  entire  week;  therefore,  this  percentage  will 
not  change  as  the  day  of  the  week  changes  in  the  completed 
model.  The  remaining  91%  of  the  Hot  Line  IPG  II  input  is  con¬ 
ditionally  routed  at  node  31  based  on  the  keypunch  service  time 
attribute.  Those  that  do  not  require  keypunch  are  forwarded 
to  Q-node  25  and  will  be  batch  processed  in  DPD.  The  remaining 


IPG  II  requisitions  leaving  node  31  are  routed  to  Customer 
Services  to  be  edited,  keypunched,  and  put  in-process.  All 
QUICK  PICs,  mechanized  or  not,  are  sent  to  Customer  Services. 

IPG  I  demands  are  divided  into  Bearers  and  Others  at  node  24 , 
assigned  a  processing  priority  designator  {attribute  3)  at 
nodes  26  and  27,  and  forwarded  to  Customer  Services.  The 
Bearer  percentage  was  developed  from  Table  5-2. 

Figure  6-6  indicates  that  SERVMART  Replenishment  requisi¬ 
tions  and  QUICK  PIC  arrive  uniformly  over  the  day.  In  actuality, 
the  SERVMART  operation  at  NSC  San  Diego  is  a  mechanized  system 
called  EPOS  (Electronic  Point  of  Sale)  which  generates  a  daily 
replenishment  tape  that  is  forwarded  to  DPD  for  overnight/ 
weekend  processing.  Therefore,  the  mark  time  for  the  SERVMART 
replenishments  will  be  premature.  However,  it  will  be  on  the 
correct  day  and  be  more  indicative  of  the  actual  delay  between 
real  time  reorder  recognition  and  the  subsequent  replenishment 
issue.  QUICK  PIC,  as  described  in  Chapter  5,  is  a  system 
featuring  the  submission  of  requisitions  at  designated  area 
locations.  They  are  picked  up  and  delivered  to  Customer  Ser¬ 
vices  during  the  day  shift,  but  are  usually  not  processed  until 
the  second  shift.  Therefore,  the  model  assumption  of  uniform 
arrival  rate  over  the  day  shift  followed  by  processing  on  the 
second  shift  does  not  introduce  a  significant  distortion  of 
reality. 

It  was  stated  that  the  percentages  indicated  on  the  branches 
leaving  node  14  represented  daily  averages  as  a  percentage  of 
total  Thursday  demand.  Consequently,  as  the  model  is  stepped 
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through  the  week,  these  percentages  should  change.  However, 
in  actual  model  operation  these  values  will  remain  constant 
and  only  node  13  and  the  interarrival  logic  associated  with 
it  will  be  revised/replaced.  This  procedure  will  theoretically 
result  in  the  volume  of  special  category  (Provisions,  Special 
Programs,  and  SERVMART)  demands  varying  proportionally  with 
the  daily  level  of  demand  as  defined  by  the  interarrival  dis¬ 
tribution.  This  appears  sufficient  in  view  of  the  Chapter  5 
discussion  of  the  nature  of  the  special  category  statistics. 

The  messenger  logic  associated  with  Q-node  25  represents 
the  continuation  of  the  routing  that  was  initiated  at  node 
83  on  Figure  6-5.  The  logic  is  identical  to  the  autodin  IPG 
I  transfer  network.  The  contents  of  Q-25  are  forwarded  from 
node  99  to  DPD  keypunch  node  100  after  encountering  the  indi¬ 
cated  delay.  When  Q-node  25  is  empty,  AT  3  =  0,  the  messenger 
departs  from  node  87  and  proceeds  to  node  70  on  Figure  7-6  to 
pick-up  IPH  I  issue  documents  destined  for  the  Broadway  ware¬ 
house  complex. 


VII.  CUSTOMER  SERVICES  AND  DPP  KEYPUNCH 

A .  Q-GERT  RESOURCES 

Prior  to  discussing  the  Customer  Services  model  segment, 
the  concept  of  Q-GERT  resources  must  be  introduced.  Figure 
7-1. portrays  a  keypunch  queue  and  service  activity  containing 
two  identical  servers . 


Attributes 
2  and  3 

assigned 
values  earlier 
in  network 


Keypunch 

queue 


Keypunch  tine  eaual  to 
attribute  2  value  of  each 
T'  transaction 

/AT  h  y 

’  ’ _ ^  To  further  processing 


□  CD 


Two  keypunch  personnel 


Figure  7-1.  Simple  Queue  and  Service  Activity 

As  servers  become  idle,  transactions  are  removed  from  Q-node 
1  and  placed  in  service  for  a  period  equal  to  the  transaction's 
attribute  2  value.  Transactions  are  ranked  in  the  Q-node  based 
on  their  attribute  3  value  with  the  smallest  value  first.  This 
simple  network  will  perform  the  keypunch  function  and  automat¬ 
ically  be  included  in  the  Q-GERT  Program  statistical  output. 
Average  transaction  waiting  time  in  Q-node  1  and  the  percentage 
of  time  each  server  is  busy  are  among  the  statistics  generated. 
This  approach  would  be  both  efficient  and  sufficient  for  des¬ 
cribing  a  single  or  double  shift  operation  as  long  as  the  number 
of  servers  remained  constant.  However,  the  second  shift  at 
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NSC  San  Diego  has  fewer  personnel  at  all  work  stations  that 
remain  active.  Therefore,  a  procedure  to  model  a  change  in 
the  number  of  servers  at  a  given  point  in  time  is  needed.  Q- 
GERT  concepts  previously  introduced  do  not  provide  this  capa¬ 
bility  although  it  may  be  possible,  with  a  great  degree  of 
difficulty,  to  devise  a  user  function  that  will  do  it.  Thus, 
the  concept  of  replacing  the  server (s)  in  a  network  segment 
with  a  variable  resource  allocation  scheme  is  illustrated  in 
Figure  7-2. 


Queue 


Selection  Rule 


ALLOCATE  type  1  that  are  needed  to 

NODE  process  a  Q-node  1  transaction 


Figure  7-2 .  Allocate  and  Free  Nodes 

Subject  to  initializing  conditions  that  will  be  presented 
later,  the  Figure  7-2  network  performs  the  same  function  as 
the  Figure  7-1  symbology.  The  resource  type  specified  on  the 
left  side  of  allocate  node  2  implies  that  resources  must  be 
categorized  and  numbered  in  accordance  with  the  function  they 
perform.  If  Q-node  1  contains  documents  to  be  keypunched,  then 
resource  type  1  must  have  a  keypunch  capability.  This  same 


resource  could,  however,  be  used  elsewhere  in  the  network 
for  dissimilar  tasks  if  appropriate.  A  RES  (Resource)  card 
is  used  to  define  each  type  of  resource,  provide  the  initial 
system  capacity,  and  list  the  allocate  nodes  associated  with 
the  resource  type.  The  following  format  could  be  used  to 
describe  the  Figure  7-2  network: 


RES,  1/KEYPNCH,  15,  2,  7,  8  * 

\l  l  X'  'v' 

Type  Descriptive  Allocate  nodes 

Label  Initial  associated  with 

for  Output  number  of  this  type  resource 
keypunchers 

Resource  Card  Example 

This  resource  designation  could  apply  if  it  was  determined 
that  keypunch  personnel  in  Customer  Services  and  DPD  were 
indistinguishable .  There  may  be  15  day  shift  keypunchers,  2 
in  Customer  Services  and  13  in  DPD,  processing  transactions 
from  the  Q-nodes  preceeding  Customer  Services  allocate  node  2 
and  DPD  allocate  nodes  7  and  8.  If  the  type  1  resource  were 
limited  to  Customer  Services  keypunchers  working  only  on  trans¬ 
actions  in  Q-node  1,  the  15  would  be  changed  to  2  and  the 
allocate  nodes  limited  to  node  2  only. 

Returning  to  Figure  7-2,  the  allocation  of  a  resource,  when 
available,  to  a  transaction  in  Q-node  1  effectively  "captures" 
that  resource  and  routes  it  with  the  transaction  until  a  free 
node  is  encountered.  Therefore,  a  resource  would  flow  with  a 


requisition  through  node  3,  encounter  a  delay  equal  to  the 
transaction  attribute  2  value,  and  then  be  released  and  re¬ 
turned  to  allocate  node  2  by  free  node  4 .  The  resource  re¬ 
mained  captured,  and  thus  unavailable,  for  the  same  period  of 
time  a  Figure  7-1  server  would  be  busy. 

Consider  the  situation  described  on  the  illustrated  RES 
card  example.  DPD  and  Customer  Services  keypunchers  were 
assumed  interchangeable.  Free  node  4  might  then  have  been 
displayed  in  one  of  the  following  ways  with  the  indicated 
allocation  scheme: 


Free  Node  Allocation  Examples 

The  multiple  allocation  designations  under  the  three  leftmost 
free  nodes  are  provided  to  illustrate  that  each  vertical  group 
ing  describes  an  identical  reallocation  scheme.  The  12,7,8] 
allocation  on  the  leftmost  node  is  identical  to  the  RES  card 
order  and  specifies  that  allocate  nodes  2,  7,  and  8  should  be 
reviewed  in  that  order  for  the  possible  allocation  of  freed 
resources.  However,  the  three  allocation  schemes  directly 


below  the  12,7,8)  indicator  provide  the  same  allocation  order 
because  all  RES  card  allocate  nodes  not  shown  under  the  free 
node  will  also  be  screened  in  the  RES  card  order.  Therefore, 
the  blank  entry  indicates  the  RES  card  order  should  be  followed. 
The  [T]  and  \2 ,1 \  schemes  achieve  the  same  effect  because  the 
remaining  allocate  nodes  using  Type  1  (keypunch)  resources 
would  be  reviewed  in  the  order  specified  on  the  RES  card. 

The  second  and  third  free  nodes  illustrated  provide  examples 
that  again  screen  all  three  allocate  nodes  using  resource  type 
1  but  specify  a  different  allocation  order  than  the  RES  card. 

The  effect  under  each  free  node  is  the  same  due  to  the  automatic 
inclusion  of  the  remaining  RES  card  nodes.  The  right-most  free 
node,  however,  will  reallocate  only  to  allocate  node  2.  The 
specification  of  the  negative  value  eliminates  the  RES  card 
review  and  limits  reallocation  attempts  to  the  ordered  sequence 
of  allocate  nodes  preceding  the  negative  value  at  the  free  node. 
Therefore,  the  designation  j  8 , 2 ,  —  1 j  results  in  an  attempt  to 
apply  freed  resources  at  allocate  node  8.  Any  remaining  re¬ 
sources  would  then  be  applied  to  allocate  node  2  if  they  were 
needed  there.  If  freed  resources  remained  after  sequential 
allocations  at  nodes  8  and  2,  they  would  become  inactive  rather 
than  applied  to  node  7. 

Any  transaction  can  be  used  to  initiate  the  freeing  of  re¬ 
sources  up  to  the  RES  card  capacity  at  a  free  node.  In  particu¬ 
lar,  the  arriving  transaction  need  not  have  resources  allocated 
to  it.  If  the  number  of  resources  to  be  freed  is  greater  than 
the  number  idle,  the  quantity  of  busy  resources  necessary  to 
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equal  the  freed  quantity  will  immediately  be  idled.  Therefore 
if  these  busy  resources  are  functioning  in  a  server  capacity, 
they  will  immediately  "leave  their  transaction"  and  prohibit 
the  modeler  from  interpreting  resource  utilization  output  as 
identical  to  server  statistics. 

Figure  7-3  illustrates  a  modeling  scheme  that  would  be 
particularly  relevant  to  stock  point  operations. 


i 


Issuing  Document 
Queue 


Receipt 

Processing 

Queue 


j 

11 

i  ! 

l 

2 

2 

i  i 

1 _ 

Issue 

Time 


2. 

Vl 


(AT, 5) 


Receipt 

Processing  Time 


3  XAT.3) 


Capacity 

('RES,  1/ISSUE,  30, 11, 21  ~31«) 
{RES,  2/RECPT,13,2,6,7Jy 


Figure  7-3.  Issue  and  Receipt  Processing 

As  defined  on  the  RES  cards ,  personnel  processing  issues  are 
categorized  as  a  different  type  of  resource  than  receipt  pro¬ 
cessors.  The  RES  card  also  illustrates  that  there  are  additional 
issue  processing  network  segments  using  allocate  nodes  21  and 
31.  The  blank  allocation  block  under  free  node  13  indicates 
the  RES  card  sequence  will  be  followed  when  allocating  freed 
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resources.  The  free  nodes  associated  with  allocation  nodes 
21  and  31  may  have  allocation  schemes  of  1  21 , 31, 2"i  and 
j  31 , 2 , 2l~l  ,  respectively,  Using  that  scheme,  all  resources 
would  "remain  in  place"  as  long  as  there  were  issues  to  be 
made.  The  receipt  processing  network  would  function  in  a 
similar  manner  although  the  receipt  processing  capacity  is 
10  (from  the  RES  card)  as  compared  to  30  issue  resources. 

Realistically,  these  two  types  of  resources  are  inter¬ 
changeable  and  a  capability  to  transfer  reousrces  between  the 
receipt  and  issue  functions  exists.  Figure  7-4  is  a  simplified 
version  of  the  Q-GERT  symbology  effecting  a  conditional  trans¬ 
fer  of  resources  based  upon  backlog  consideration.  This  exam¬ 
ple  will  serve  to  introduce  the  AL  (Alter)  node,  which  is  used 
to  change  the  resource  capacity  specified  on  the  RES  card. 

At  node  30,  an  arriving  transaction  is  assigned  an  attri¬ 
bute  1  value  computed  by  UF  (User  Function)  7.  This  FORTRAN 
subprogram  would  examine  the  issue  and  receipt  Q-nodes  to 
determine  whether  resources  should  be  transferred  from  issue 
to  receipt  processing  (A1  =  1),  receipt  processing  to  issue 
(A1  =  2)  ,  or  remain  as  assigned  on  the  RES  card  (Al  =  3) .  A 
second  user  function,  which  is  designated  UF8,  will  compute 
the  number  of  resources  to  be  transferred  and  assign  that  value 
to  attribute  2  of  the  transaction.  The  conditional-take-first 
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branching  from  node  30  is  based  on  the  attribute  1  value  assigned 
and,  if  the  user  functions  indicate  that  resources  should  be 
shifted  from  issue  (Type  1)  to  receiving  (Type  2)  ,  the  upper 
branch  will  be  taken.  Alter  node  40  will  reduce  the  Figure  7-3 
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Figure  7-4.  Alter  Node  Network 

RES  card  capacity  of  30  by  the  value  of  attribute  2  of  the 
arriving  transaction.  However,  unlike  the  free  node,  the 
alter  node  will  wait  until  resources  are  idle  before  seizing 
them.  Alter  node  41  will  then  increase  the  receiving  resources 
by  A2  units  and  allocate  them  as  specified  on  the  RES  card  and 


described  in  the  free  node  discussion.  The  eight  hour  delay 
on  the  deterministic  branching  from  node  41  indicates  the 
resources  will  remain  reassigned  the  entire  workday  and  then 
altered  to  equal  the  original  RES  card  capacities  at  nodes 
42  and  43.  The  transaction  leaving  node  42  departs  the  sys¬ 
tem;  node  43  output  is  assigned  a  16  hour  delay  then  routed 
back  to  node  30  to  initiate  the  backlog  evaluation  process 
again. 

The  second  branch  (A1  =  2)  operates  in  a  similar  manner 
but  transfers  assets  from  receiving  (Type  2)  to  issue  for  the 
day.  If  it  is  determined  that  no  resource  shifts  are  required, 
the  bottom  branch  (Al  =3)  is  taken  from  node  30  and  a  24  hour 
delay  is  encountered  before  the  next  backlog  evaluation. 

The  applicability  of  resource  capacity  altering  to  the 
modeling  of  breaks  and  shift  changes  should  be  apparent.  A 
resource  allocation  network  could  even  be  used  to  provide  a 
messenger  service;  the  amount  of  the  messenger  resource  made 
available  by  an  alter  node  could  be  set  to  a  constant  value 
or  even  equated  to  the  number  of  queued  transactions  waiting 
to  be  routed.  After  the  routing  was  completed,  the  messenger 
capacity  would  immediately  be  altered  to  zero  to  preclude  the 
movement  of  transactions  before  the  next  scheduled  messenger  run. 

B.  CUSTOMER  SERVICES 

The  Q-GERT  representation  of  the  NSC  San  Diego  two  shift 
Customer  Services  operation  is  shown  on  Figures  7-5  and  7-6. 
Autodin  IPG  I  input  from  node  84  on  Figure  6-5  and  POE  input 
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from  nodes  26,  27,  31,  and  32  on  Figure  6-6  are  shown  enter¬ 
ing  the  edit  queue,  Q-node  33.  Nodes  34  through  36  model  the 
edit  server  as  a  resource  as  described  earlier  in  this  chapter. 
The  time  to  edit,  which  is  indicated  .by  the  delay  on  the  branch 
between  nodes  35  and  36,  is  a  constant  0.002  hours  (7.2  seconds) 
as  specified  in  reference  (b) .  The  RES  card  image  shown  under 
node  34  indicates  there  is  one  unit  of  the  edit  resource  that, 
when  freed,  is  to  be  allocated  at  node  53,  then  34.  Node  53, 
which  is  part  of  the  second  shift  exception  processing  network 
in  the  lower  left  portion  of  Figure  7-5,  is  discussed  below. 
During  the  day  shift,  the  edit  resource  will  be  processing 
requisitions  from  Q-node  33  only.  The  free  node  36  allocation 
scheme  of  [53 , 34 ]  is  identical  to  the  RES  card  and  therefore 
could  have  been  omitted. 

The  conditional-take-f irst  branching  from  node  36  functions 
to  provide  special  processing  for  QUICK-PIC  transactions.  They 
are  modeled  as  being  edited  upon  arrival  and  then  stored  in 
Q-node  37  until  released  by  a  timing  network  transaction  arriving 
at  node  39.  Once  again  the  requisition  transfer  system  des¬ 
cribed  in  Chapter  6  effects  the  instantaneous  timed  release  of 
the  QUICK  PIC  transactions  from  node  41  to  either  node  43  if 
keypunch  is  required,  or  to  DPD  if  mechanized  (A2.EQ.0).  The 
model  will  provide  the  transfer  at  1800  on  each  working  day 
for  the  following  two  reasons:  (1)  QUICK  PIC,  with  an  A3  =  3 
designator,  should  be  withheld  from  the  keypunch  S/3-ranked 
queue  (Q-node  43)  long  enough  to  maximize  the  number  of  non- 
rr.echanized  IPG  II  demands  (A3  =  4)  placed  in-process  before 
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Figure  7-5.  Customer  Services  (Part  1) 


the  1800  backorder/in-process  release  program  is  run  in  DPD; 
and  (2)  once  entering  the  keypunch  queue,  the  relatively  small 
attribute  3  value  should  ensure  all  QUICK  PICs  are  keypunched 
prior  to  the  end  of  the  second  shift.  Theoretically,  QUICK 
PIC  processing  will  cease  only  upon  the  arrival  of  an  autodin 
IPG  I;  POE  input  terminates  at  1600  in  the  model.  A  discussion 
of  the  IPG  II  in-process  and  subsequent  release  relationship 
was  presented  in  Chapter  5. 

The  requisitions  routed  from  node  36  to  node  43  via  regu¬ 
lar  node  42  will  be  Bearers,  other  IPG  Is,  and  IPG  IIs.  Each 
category  will  not  only  be  keypunched  if  necessary  (A2.NE.0), 
but  will  also  be  entered  for  remote  processing.  Since  the 
nodes  44  through  46  resource  allocation  network  performs  the 
joint  keypunch  and  enter  action  based  upon  the  transaction's 
attribute  2  value,  an  entry  time  of  0.0015  hours,  or  approxi¬ 
mately  5  seconds,  is  added  to  the  keypunch  time  at  node  42. 

The  transactions  are  then  routed  to  Q-node  43  where  they,  and 
QUICK  PICs  arriving  at  1800,  are  processed  by  the  CSKEY  (Cus¬ 
tomer  Services  Keypunch)  resources  illustrated  on  the  RES  card 
image  under  allocate  node  44.  The  indicated  day  shift  capacity 
of  two  will  be  reduced  to  one  at  1600  each  day  by  an  alter  node 
in  the  timing  network.  Note  that  two  Q-nodes,  43  and  61,  con¬ 
tain  transactions  that  use  Customer  Services  keypunch  resources. 
Demand  exceptions  and  warehouse  refusals  for  all  requisition 
categories  are  processed  by  the  Exception  Unit  and  returned  to 
Q-node  43  or  61  for  exception  keypunch  and,  except  for  QUICK 
PIC,  immediate  entry.  If  there  are  transactions  in  both  Q-nodes, 
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the  queue  selection  priority  scheme  located  in  the  upper  left 
partition  of  allocate  node  44  is  used  to  determine  the  next 
transaction  processed  when  resources  are  freed. 

Table  7-1,  which  was  reproduced  from  reference  (a),  lists 
the  queue  selection  rules  that  may  be  specified  at  either 
allocate  nodes  or  S-nodes  (Selector  nodes) .  The  ASM  (Assembly 
Mode)  option  listed  last  in  the  table  may  only  be  used  at  S- 
nodes.  Allocate  node  56  on  Figure  7-5  was  originally  modeled 
as  an  S-node.  The  description  of  the  node  56  demand  exception 
processing  network  will  include  an  introduction  to  the  use  of 
S-nodes . 

The  POR  (Preferred  Order)  specification  at  allocate  node 
44  was  selected  as  the  most  realistic  option  available  in 
Table  7-1.  Assume  that  Q-node  61  was  not  included  and  all 
processed  exceptions  leaving  node  60  were  routed  to  Q-node  43 
and  ranked  as  indicated  by  their  attribute  3  value.  Since  de¬ 
mand  exceptions  are  encountered  on  all  requisition  categories 
except  SERVMART  and  provisions  (attribute  3  values  from  1  to 
5) ,  the  large  volume  of  higher  priority  demands  arriving  at 
Q-node  43  could  possibly  delay  the  keypunching  and  reentry  of 
IPG  III  exceptions  for  an  inordinately  long  period.  In  reality, 
demand  exceptions  are  not  processed  on  a  strict  priority  basis 
by  the  Exception  Unit.  Exceptions  often  arrive  at  keypunch 
batched  by  type  of  exception  and  containing  both  IPG  II  and 
III  requisitions.  Keypunch,  in  turn,  will  process  the  entire 
batch  sequentially  unless  interrupted  by  the  arrival  of  an  IPG 
I.  Therefore,  requisitions  having  large  attribute  3  values 
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Table  7-1.  Priority  rules  associated  with  allocate 
and  S-nodes  for  selecting  from  parallel  queues 


Code 


Definition 


POR 

CYC 

RAN 

LAV 

SAV 

LWF 

SWF 

LNQ 

SNQ 

LNB 

SNB 

LRC 

SRC 

ASM 


Priority  given  in  a  preferred  order. 

Cyclic  Priority  -  transfer  to  first  available 
Q-node  starting  from  the  last  Q-node  that  was 
selected. 

Random  Priority  -  assign  an  equal  probability  to 
each  Q-node  that  can  be  selected. 

Priority  given  to  the  Q-node  which  has  had  the 
largest  average  number  of  transactions  in  it  to 
date. 

Priority  is  given  to  the  Q-node  which  has  had  the 
smallest  average  number  of  transactions  in  it  to 
date. 

Priority  is  given  to  the  Q-node  for  which  the 
waiting  time  of  its  first  transaction  from  its 
last  marking  is  the  longest. 

Priority  is  given  to  the  Q-node  for  which  the 
waiting  time  of  its  first  transaction  from  its 
last  marking  is  the  shortest. 

Priority  is  given  to  the  Q-node  which  has  the 
current  largest  number  of  transactions  in  it. 
Priority  is  given  to  the  Q-node  which  has  the 
current  smallest  number  of  transactions  in  it. 
Priority  is  given  to  the  Q-node  which  has  had 
the  largest  number  of  balkers  from  it  to  date. 
Priority  is  given  to  the  Q-node  which  has  had  the 
smallest  number  of  balkers  from  it  to  date. 
Priority  is  given  to  the  Q-node  which  has  the 
largest  remaining  unused  capacity. 

Priority  is  given  to  the  Q-node  which  has  the 
smallest  remaining  unused  capacity. 

Assembly  mode  option  -  all  incoming  queues  must 
contribute  one  transaction  before  a  processor  may 
begin  service  (this  can  be  used  to  provide  an 
"AND"  logic  operation);  S-nodes  only. 
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aren't  actually  waiting  as  long  as  a  direct  input  into  Q-node 
43  would  theoretically  cause.  This  observation  indicated  that 
the  addition  of  a  second  Q-node  for  exception  unit  output  was 
advisable.  Consideration  was  given  to  routing  all  exceptions 
to  Q-node  61,  which  would  be  assigned  an  S/3  ranking,  and  estab¬ 
lishing  a  POR  (Preferred  Order)  queue  selection  rule  at  allocate 
node  44  with  Q-node  43  as  the  preferred  queue.  This  procedure 
would  inhibit  any  processing  of  node  61  exceptions  unless 
Q-node  43  was  empty.  The  expected  volume  at  node  43  caused 
the  rejection  of  this  approach;  a  large  percentage  of  incoming 
requisitions  will  pass  through  Q-node  43  while  only  6.2%  of 
all  demands  will  encounter  exceptions.  Similar  volume  considera¬ 
tions  led  to  discarding  an  "all  exceptions  to  node  61,  LNQ 
queue  selection"  approach  with  an  S/3  ranking  procedure  in  the 
queue.  Although  this  technique  would  place  warehouse  refusals 
and  IPG  Is  (attribute  3  values  of  0,  1,  and  2)  at  the  head  of 
Q-node  61,  it  again  appeared  likely  that  the  high  volume  in 
node  43  would  preclude  the  actual  expeditious  processing 
afforded  warehouse  refusals  and  IPG  Is.  Therefore,  the  indi¬ 
cated  compromise  routing  was  established.  Warehouse  refusals 
and  IPG  Is  are  routed  on  the  A3.LE.2  branch  to  the  higher  volume 
queue,  node  43,  where  they  are  ranked  on  a  "smallest  value  of 
attribute  3"  basis.  This  places  warehouse  refusals,  which 
possess  a  zero  attribute  3  value,  first  in  the  queue  and  models 
NSC  San  Diego  management  policy.  The  IPG  Is,  having  attribute 
3  values  of  1  and  2,  will  therefore  be  processed  directly  after 
the  warehouse  refusals  to  reflect  the  special  management  attention 


given  this  category  by  Customer  Services.  The  S/3  ranking 
in  exception  processing  Q-nodes  49  and  52  also  implies  a 
strict  priority  exception  processing  procedure  is  used.  While 
this  is  always  true  for  the  IPG  Is  and  the  IPG  I Is  put  in- 
process  at  Customer  Services  keypunch,  recall  that  it  is  not 
completely  factual  for  batch  processed  IPG  II  and  III  excep¬ 
tions  arriving  at  Q-node  49.  Therefore,  an  F  (First-In-First 
Out)  queue  ranking  rule  was  specified  at  Q-node  61  to  model 
the  actual  occurrence  of  IPG  III  exceptions  being  reentered 
by  Customer  Services  before  IPG  IIs  originating  at  a  later 
batch  run.  This  modeling  approach  will  partially  offset  the 
somewhat  erroneous  strict  priority  processing  technique  used 
in  the  Exception  Unit. 

An  LNQ  (Largest  Number  in  Queue)  designation  at  allocate 
node  44  would  have  modeled  a  cyclic  processing  procedure  once 
the  queues  contained  the  same  number  of  transactions.  This 
was  considered  too  great  a  departure  from  reality.  Therefore, 
the  POR  option  with  Q-node  43  preferred  was  selected  despite 
the  much  higher  volume  arriving  at  Q-node  43.  This  technique 
will  result  in  batch  keypunch  and  entry  of  IPG  II  and  III 
exceptions  on  a  FIFO  basis  once  the  processing  of  the  contents 
of  Q-node  61  begins;  i.e.,  when  Q-node  43  is  empty.  This 
approach  is  more  realistic  than  it  may  appear.  The  technique 
used  should  result  in  IPG  II  and  III  exeptions  begin  batch 
processed  on  the  Customer  Services  evening  shift,  which  is 
precisely  what  actually  often  occurs.  The  foregoing  discussion 
emphasizes  the  complexity  of  the  exception  processing/Customer 


Services  keypunch  relationship  and  presents  the  myriad  fac¬ 
tors  that  entered  into  the  modeling  decision. 

Returning  to  Figure  7-5  at  free  node  46,  the  keypunched 
QUICK-PIC  requisitions,  which  were  not  entered  by  Customer 
Services,  are  removed  and  forwarded  to  a  special  DPD  queue. 

The  remaining  transaction  are  assessed  a  variable  delay  prior 
to  node  47  to  represent  remote  processing  time.  Although 
entering  a  requisition  frees  the  keypunch  resource,  the  trans¬ 
action  is  delayed  until  processing  is  completed.  Activation 
of  the  on-line  remote  demand  processing  program  is  based  upon 
time-volume  considerations.  Requisitions  entered  through  remote 
terminals  are  queued  and  processed  at  six  minute  intervals 
unless  30  transactions  accumulate  before  the  time  expires. 
Nevertheless,  delays  in  the  receipt  of  a  response  (issue  docu¬ 
ment,  referral,  or  exception)  that  exceeded  15  minutes  were 
frequently  observed.  Lengthy  delays  were  probably  attributa¬ 
ble  to  time  awaiting  the  issue  document  punch  routine,  a  rela¬ 
tively  slow  operation  when  compared  to  CPU  processing  times. 

In  additiona,  two  minute  turnaround  times  were  noted  during 
low  workload  periods  when  a  six  minute  wait  could  reasonably 
be  expected.  Therefore,  the  processing  time  assigned  at  node 
42  will  be  taken  from  a  normal  distribution  having  a  mean  of 
eight  minutes  and  a  standard  deviation  of  2.5  minutes.  Mini¬ 
mum  and  maximum  processing  times  of  two  and  17  minuts  are  also 
specified. 

The  branching  from  node  47  models  the  6.2%  demand  exception 
rate  developed  in  Chapter  5.  During  the  day  shift,  exceptions 


occurring  from  Customer  Services  remote  entries  will  be 
routed  through  node  48  to  Q-node  49  where,  via  allocate  node 
56,  three  type  8  resources  (servers)  are  available  to  process 
them  at  the  reference  (c)  DIMES  rate  of  0.0271  hours  (1.626 
minutes)  per  transaction  indicated  between  nodes  57  and  140. 

The  POR  designation  at  allocate  node  56  gives  Q-node  50  pro¬ 
cessing  priority  over  Q-node  49.  Therefore,  exception  processing 
on  all  requisition  categories  in  Q-node  49  -  from  both  remote 
and  batch  input  -  is  delayed  until  the  QUICK  PIC  demand  excep¬ 
tions  and  warehouse  refusals  residing  in  Q-node  50  have  been 
completed.  While  this  approach  may  appear  to  introduce  an 
unacceptable  delay  on  IPG  I  and  II  transactions  residing  in 
Q-node  49,  the  relatively  small  expected  volume  in  the  priority 
queue  should  eliminate  any  extraordinary  delays.  QUICK  PIC 
exceptions,  which  can  be  epxected  to  occur  at  a  6.2%  rate  on 
less  than  200  transactions  per  day,  will  all  appear  at  the  head 
of  Q-node  50  at  the  beginning  of  each  working  day  and  immediately 
be  processed  when  resources  become  available  at  0730.  Ware¬ 
house  refusals,  on  the  other  hand,  not  only  occur  at  a  relatively 
low  1%  (of  issues)  rate,  but  are  also  routed  by  messenger  with 
nearly  two  hours  between  scheduled  arrivals.  Therefore,  with 
three  exception  processing  resources  available,  considerable 
attention  will  be  given  to  Q-node  49  exceptions  in  the  period 
between  warehouse  refusal  arrivals.  The  B/3  ranking  scheme 
at  Q-node  50  ensures  that  QUICK  PICs,  with  the  bigger  attribute 
3  value  of  3,  are  processed  before  warehouse  refusals. 
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The  network  segment  consisting  of  nodes  56,  57,  and  140 
was  originally  modeled  using  the  S-node  logic  shown  below. 


QUEUE 

SELECTION 


The  POA  designation  in  the  queue  selection  partition  functions 
exactly  like  the  identical  specification  in  an  allocate  node. 

Any  of  the  queue  selection  rules  listed  in  Table  7-1  can  be 
used  with  an  S-node.  In  addition,  a  server  selection  priority 
rule  may  be  specified  in  the  lower  left  partition  if  a  choice 
between  dissimilar  servers  must  be  made.  Since  the  S-node  above 
routes  transactions  to  three  identical  demand  exception  servers 
at  the  activity  designated  number  (Tj  ,  no  server  selection 
rule  was  required.  Chapter  5  of  reference  (a)  details  numerous 
modeling  enhancements  that  can  be  realized  through  the  use  of 
various  permutations  of  the  queue  and  server  selection  rules. 

The  S-node  approach  was  discarded  because  the  servers  could 
not  be  removed  or  reduced  when  the  shift  ended.  Therefore,  the 
processing  of  backlogged  transaction  in  Q-node  49  will  continue 
during  the  evening  and  midnight  shifts  until  the  queue  is  empty. 
This  condition  invalidated  the  S-node  approach;  exceptions 


remaining  in  Q-node  49  at  the  end  of  the  normal  working  day 
will  not  be  processed  until  the  servers  become  available  again 
the  following  day.  Therefore,  a  resource  allocation  approach, 
which  permits  the  application  and  removal  of  resources  from 
the  timing  network,  was  adopted  to  replace  the  S-node  network. 

After  an  exception  has  been  processed,  it  is  routed  to  free 
node  140  where  the  exception  processing  resource  is  freed 
and  the  indicated  branching  occurs  to  preclude  assigning  an 
entry  time  to  QUICK  PIC  transactions.  The  time  to  keypunch 
an  exception  is  assumed  to  equal  the  standard  requisition 
keypunch  time  of  0.0071  hours.  Following  the  node  58  or  59 
keypunch  processing  time  assignment,  the  previously  mentioned 
node  60  conditional  branching  to  the  Customer  Services  queues 
occurs.  QUICK  PICs  encountering  exceptions  are  not  expedited 
in  an  attempt  to  make  the  1400  deadline.  Upon  discovering 
that  his  material  is  not  available  for  pick-up,  the  customer 
has  the  option  of  coming  in  and  obtaining  the  material  as  a 
Bearer  or  waiting  an  additional  24  hours.  Actually,  the  QUICK 
PIC  exception  would  be  processed  before  queuing  for  the  late 
evening  transfer  to  DPD.  However,  sending  it  to  Q-node  37  and 
clearing  the  exception  after  1800  introduces  no  erroneous  de¬ 
lays  while  eliminating  the  need  for  more  complex  branching. 

The  foregoing  discussion  applied  to  day  shift  exception 
processing.  If  an  exception  occurs  on  a  requisition  entered 
by  the  Customer  Services  second  shift,  it  will  be  transfered 
from  node  48  to  node  51  by  means  of  a  Q-GERT  technique  called 
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nodal  modification.  The  symbology  shown  between  nodes  48  and 
51  can  be  interpreted  in  the  following  way: 

.  Upon  completion  of  activity  i,  which  will  be  an  8.5 
hour  delay  in  the  timing  network  to  represent  the  day 
shift,  node  51  will  replace  node  48. 

.  Node  51  will  remain  in  the  network  until  activity  j 
has  been  completed  to  signal  the  end  of  the  second 
shift . 

While  node  51  is  in  the  network,  transactions  (exceptions) 
arriving  at  node  48  will  be  rerouted  to  node  51  and  forwarded 
to  Q-node  52,  the  second  shift  exception  processing  queue. 
Allocate  node  53  indicates  that  resource  type  1  is  used  to 
correct  the  exception.  Free  node  55  attempts  to  reallocate 
freed  resources  at  nodes  53  and  34,  which  follows  Q-node  33, 
the  edit  queue.  Free  node  36  of  the  edit  resource  network  also 
attempts  to  reallocate  at  node  53  first.  During  the  day  shift, 
an  allocation  at  node  53  will  not  be  made  because  Q-node  52 
will  be  empty;  i.e.,  no  exceptions  are  being  routed  there  until 
after  1600.  However,  during  the  second  shift,  editing  of  Q-node 
33  will  terminate  when  an  exception  occurs  because  the  edit 
resource,  when  freed  at  node  36,  will  be  allocated  to  the  excep¬ 
tion  first.  The  model  is  realistic.  Editing  is  interrupted 
to  process  exceptions  occurring,  in  general,  on  autodin  IPG  Is 
and  IPG  IIs  being  put  in-process.  Of  course,  requisitions  and 
exceptions  remaining  in  Q-nodes  43  and  63  after  the  day  shift 
are  also  being  keypunched  and/or  entered.  The  routing  from 
node  55  need  not  incorporate  the  QUICK  PIC  consideration  modeled 
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by  node  57;  QUICK  PICs  are  not  entered  from  Customer  Services 
by  remote  and  all  exceptions  originating  in  the  special  QUICK 
PIC  overnight  batch  run  arrive  at  Q-node  50  each  morning. 

Requisitions  branching  without  exception  from  node  47  are 
first  subjected  to  the  conditional  branching  at  node  62  where 
Warehouse  refusals  are  removed.  The  existence  of  a  warehouse 
refusal  indicates  that  material  was  not  available  and,  theoret¬ 
ically,  the  modeled  referral  will  automatically  occur.  In 
practice,  material  sometimes  does  become  available  from  a 
variety  of  sources.  However,  no  attempt  will  be  made  to  model 
the  numerous  factors  that  can  invalidate  a  warehouse  refusal. 

The  NSC  San  Diego  February  1980  material  availability  or  POE 
(Point  of  Entry)  effectiveness  percentage  of  68%  is  applied 
at  node  63.  Requisitions  branching  as  not  available  (referrals) 
are  routed  to  node  65  on  Figure  7-6  along  with  the  referrals 
originated  by  warehouse  refusals.  Requisitions  that  can  be 
satisfied  are  routed  to  node  64.  All  IPG  II  and  III  demands 
are  sent  to  the  DPD  in-process  queue  where  they  will  be  released 
at  1800  daily.  Although  no  IPG  Ills  entered  Customer  Services 
at  the  edit  queue,  they  do  arrive  as  exceptions  which,  when 
corrected,  are  put  in-process  by  keypunch  resources.  IPG  Is 
branch  from  node  64  as  either  Bearers  or  Others  due  to  the  dis¬ 
tinct  processing  differences  shown  in  Figure  7-6. 

As  indicated  by  the  branching  from  nodes  69  and  95  on 
Figure  7-6,  it  will  be  assumed  that  15%  of  all  demand  (provi¬ 
sions  excluded)  is  for  material  warehoused  at  the  National  City 
complex.  The  remaining  85%  is  lodged  against  assets  at  the 
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Broadway  location  with  bin  and  bulk  material  contributing  65% 
and  20%,  respectively.  The  IPG  Is  were  subcategorized  at 
node  64  (Figure  7-5)  prior  to  the  location  designation  to 
ensure  each  subcategory  would  be  assigned  a  representative 
National  City  issue  percentage.  A  separate  messenger  service 
transports  non-Bearer  IPG  Is  to  National  City.  The  network 
representing  this  document  flow  consists  of  nodes  70  through 
75  plust  90  on  Figure  7-6.  Although  it  is  not  included  in 
the  model,  an  IPG  I  processing  idiosyncracy  should  be  mentioned; 
all  IPG  I  issue  documents.  Bearer  or  Other,  are  printed  and 
output  at  Customer  Services  (Broadway)  regardless  of  the  material 
location.  There  is  a  remote  terminal  at  National  City  through 
which  requisition  entry  is  initiated.  However,  even  if  an  IPG 
I  request  for  National  City  material  were  entered  there,  the 
issue  document  would  have  to  be  obtained  from  Broadway  (Cus¬ 
tomer  Services)  and  transported  back  to  National  City  by  the 
Bearer  or  messenger.  Since  National  City  entry  workload  is 
included  in  the  reference  (e)  totals  and  all  IPG  I  issue  docu¬ 
ments  originate  in  Customer  Services,  a  separate  National  City 
entry  station  in  the  model  was  not  considered  necessary.  The 
existing  NSC  San  Diego  procedure  introduces  IPG  I  processing 
delays  for  National  City  material.  Bearers  may  encounter  a 
delay  equal  to  the  time  of  a  round  trip  to  National  City.  Other 
IPG  Is  for  National  City  material  will  normally  be  entered  at 
Broadway  and  will  experience  a  delay  that  depends  on  the  timing 
of  the  next  National  City  messenger  run.  Therefore,  the  only 
delay  missing  in  the  model  is  the  Bearer  travel  time  from 
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cussed  above,  is  normally  distributed  with  a  possible  maximum 
of  17  minutes. 

Following  the  issue  category  determination  at  nodes  65 
and  95,  identical  DIMES  issue  time  standards  are  assigned  as 
attribute  5  to  Bearers  at  nodes  96  through  98  and  to  Other 
I PH  Is  at  nodes  70,  76,  and  77.  The  Broadway  bin  issue  time 
of  0.068  hours  is  a  hot  line  issue  time  in  contrast  to  the 
lower  AMHS  (Automated  Material  Handling  System)  bin  issue  time 
of  0.45  hours  for  requisitions  lotted  in  DPD .  An  IPG  I  bin 
issue  functions  as  an  interrupt  to  AMHS  lotted,  location  se¬ 
quenced  bin  issues.  This  random  deviation  from  the  lotted 
location  pattern  will  normally  increase  the  issue  time. 

The  constant  delays  on  the  branches  from  nodes  96  through 
98  represent  Bearer  travel  times  to  the  appropriate  warehouse. 

The  network  associated  with  match  node  74  represents  the  National 
City  driver/messenger.  The  logic  for  removing  the  transaction (s) 
from  Q-node  70  is  identical  to  the  Chapter  6  messenger  descrip¬ 
tion.  However,  this  messenger  will  always  be  dispatched  from 
the  timing  network  and,  as  shown  on  the  branch  from  node  73, 
the  trip  will  not  be  made  if  there  are  no  IPG  Is  to  take.  Since 
the  messenger  will  return  from  National  City  with  warehouse 
refusals,  a  portion  of  them  may  also  experience  a  longer  delay 
than  usual. 
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The  match  node  91  messenger  will  be  arriving  from  the 
Figure  6-6  node  87  network  during  the  day  shift.  Since  this 
is  the  regular  message  service,  the  trip  to  the  warehouse  via 
node  94  will  be  made  regardless  of  the  status  of  Q-node  78. 

The  second  shift  messenger  runs,  while  less  frequent,  will  in¬ 
clude  all  stops  made  on  the  day  shift.  However,  they  will  be 
initiated  from  a  distinct  network  timing  segment  to  facilitate 
revisions  in  subsequent  versions  of  the  model.  For  example, 
decision  logic  to  inhibit  messenger  travel  if  Q-node  78  were 
empty  could  be  incorporated  into  the  disjoint  timing  network 
on  Figure  10-3. 

The  final  Figure  7-6  network  segment  to  be  discussed  is 
the  referral  statistics  summary  performed  by  nodes  65  through 
68.  Batch  and  POE  referrals  plus  warehouse  refusals  are  routed 
to  node  65  for  a  time  between  referrals  computation.  The  Q- 
GERT  analysis  Program  will  provide  a  histogram  of  interarrival 
times  based  upon  user  defined  cell  divisions  as  specified  on 
the  the  STAtistics  node  65  input  card.  Similar  histograms  for 
Interval  statistics  will  be  generated  at  nodes  66  through  68. 
The  branching  from  node  65  splits  the  referrals  into  IPG  I 
through  III  requisitions.  Interval  statistics  refer  to  the 
time  between  the  last  requisition  mark  time,  which  is  the 
arrival  time  in  the  model,  and  the  arrival  of  the  transaction 
at  the  node  effecting  the  collection  of  interval  statistics. 

Had  attribute  3  been  used  to  distinguish  between  autodin  and 
POE  demands  within  each  IPG,  separate  referral  statistics  could 
have  been  maintained  on  each  major  category.  This  enhancement 
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would  be  particularly  useful  if  autodin  IPG  referrals  could 
be  isolated  during  input  categorization  and  assigned  a  distinct 
attribute  value.  First,  since  these  transactions  have  already 
been  referred  by  the  POE  stock  point  and  rerouted  by  the  ICP, 
the  allowable  processing  time  is  decreased.  Finally,  the  ICP 
rerouting  was  initiated  based  on  visibility  of  the  NSC  San 
Diego  asset  position  through  the  TIR  (Transaction  Item  Reporting) 
process.  Therefore,  a  subsequent  NSC  San  Diego  referral  on 
this  type  of  transaction  either  indicates  a  record  discrepancy 
or  is  prompted  by  the  real  time  lag  in  the  TIR  procedure. 

It  must  be  emphasized  that  the  referral  statistics  collected 
at  nodes  65  through  68  were  specified  by  the  node  input  cards 
and  represent  the  most  elementary  statistics  gathering  tech¬ 
nique  available  in  Q-GERT.  An  entire  chapter  in  reference  (a) 
is  devoted  to  the  collection  of  user  designated  statistics 
by  means  of  program  inserts  accessing  established  Q-GERT  sub¬ 
routines.  Therefore,  the  complexity  of  the  statistical  output 
is  a  modeling  decision  that  is  not  limited  to  the  standard 
statistics  node  options  of  First  release.  All  releases,  time 
Between  releases.  Interval  times,  and  Delay  from  first  arriving 
transaction  to  nodal  release.  The  latter  designation  would 
be  of  interest  only  if  transactions  were  being  accumulated 
before  being  released. 

C.  DATA  PROCESSING  DEPARTMENT  KEYPUNCH 

The  processing  taking  place  in  DPD  keypunch  is  presented 
in  Figure  7-7.  Requisitions  are  transported  by  messenger 
from  node  99  on  Figure  6-6  to  regular  node  100.  Arriving 
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Figure  7-7.  DPD  Keypunch 


transactions  include  SERVMART ,  Special  Programs,  Provisions, 

POE  IPG  II  mechanized  1348s,  and  all  POE  IPG  III  demands. 

That  is,  requisitions  from  all  categories  routed  to  Q-node 
25  on  Figure  6-6  are  delivered  by  messenger  to  node  100  where 
the  indicated  conditional  branching  occurs. 

All  mechanized  input  is  branched  from  node  100  to  Q-node 
6,  the  batch  processing  Q-node  from  Figure  6-5.  Therefore, 
all  mechanized  input  including  SERVMART  replenishment  requisi¬ 
tions  will  be  processed  during  the  next  scheduled  batch  run 
after  their  arrival.  This  treatment  of  SERVMART  replenishments 
is  erroneous  in  that  the  entire  replenishment  tape  is  actually 
processed  during  the  same  batch  run.  However,  since  SERVMART 
requests  will  subsequently  be  delayed  a  day  by  Production  Planning, 
the  overall  time  in  the  system  will  not  be  increased  through 
the  multiple  batch  technique  used.  As  mentioned  in  Chapter  6, 
it  was  the  choice  of  a  modeling  technique  through  which  SERVMART 
replenishments  arrive  periodically  during  the  day  rather  than 
all  at  once  that  leads  to  an  increased  time  in  the  system  for 
this  demand  category. 

Nonmechanized  DD  1348s,  all  Special  Program  requests,  and 
provisions  demands  are  segregated  at  node  100  and  sent  to  Q- 
nodes  102,  110,  and  106,  respectively,  to  await  the  availa¬ 
bility  of  DPD  keypunch  resources.  DD  1348s  from  Q-node  102 
will  be  processed  in  the  resource  allocation  network  consisting 
of  nodes  103  through  105.  As  indicated  on  the  RES  card  image 
above  allocate  node  103,  two  type  3  resources  designated  REGKP 
will  be  available  to  keypunch  DD  1348s.  Similarly,  one  type 
4  PROVKP  resource  has  been  provided  to  keypunch  provisions 
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requests  in  the  nodes  106  through  109  network  segment.  The 
output  symbology  on  the  Special  Programs  queue,  Q-node  110, 
indicates  that  either  resource  type  3  or  4  will  keypunch  these 
requests.  However,  the  POR  designator  on  allocate  nodes  103 
and  107  will  prohibit  the  processing  of  Special  Program  require¬ 
ments  by  either  resource  type  until  the  respective  preferred 
Q-node,  102  or  106,  is  empty. 

The  three  keypunch  resources  specified  on  Figure  7-7  will 
be  active  on  the  day  shift  only.  The  indicated  modeling  approach 
leads  to  the  continuous  processing  of  a  particular  demand  cate¬ 
gory  prior  to  shifting  resources  to  a  different  input  type. 

A  punch-to-disk  system  featuring  the  establishment  of  a  dis¬ 
tinct  record  content  format  for  each  input  category  is  used 
during  actual  operations.  Therefore,  once  a  specific  format 
has  been  established,  requests  corresponding  to  that  format 
are  sequentially  keypunched  until  management,  or  the  absence 
of  additional  input,  mandates  a  shift  to  a  different  input 
type.  No  attempt  has  been  made  to  model  the  management  peroga- 
tive  mentioned  above.  However,  it  is  assumed  that  the  approach 
used  will  permit  batch  keypunching  of  Special  Program  requests 
due  to  the  periodic,  vice  continuous,  arrival  of  requisitions 
by  messenger. 

Reference  (b)  allotted  four  DPD  keypunch  operators.  Based 
upon  the  Appendix  C  workload  summary,  an  initial  allocation  of 
three  personnel  to  keypunch  and  verify  has  been  established. 

The  provisioning  resource  was  purposely  categorized  as  a  dis¬ 
tinct  resource  type  to  model  the  special  attention  that  provisions 
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actually  receive.  DPD  keypunch  resources  will  be  removed  for 
a  1.5  day  period  every  other  week  to  model  the  existing  pay¬ 
roll  processing  interrupt.  This  resource  removal,  as  well  as 
all  other  resource  altering  actions,  will  be  initiated  in  the 
timing  network.  It  should  be  noted  that  a  resource  allocation 
scheme  similar  to  the  issue/receiving  example  presented  earlier 
in  this  chapter  could  be  used  to  alter  DPD  keypunch  resources 
based  on  the  volume  in  Q-nodes  102,  106,  and  110. 

After  keypunching  is  completed,  Special  Program  requests, 
both  IPG  II  and  III,  are  routed  from  free  nodes  105  and  109 
to  node  111.  The  delay  initiated  on  the  branch  leaving  node 
111  represents  the  standard  program  pricing  delay  experienced 
by  all  Special  Program  transactions.  Based  upon  the  limited 
information  available  to  quantify  this  delay,  a  normal  dis¬ 
tribution  having  a  mean  of  7.5  days,  a  standard  deviation  of 
1  day,  a  minimum  of  5  days,  and  a  maximum  of  10  days  was  chosen 
as  representative  of  a  pricing  cycle  that  "may  take  up  to  10 
days"  to  complete.  Note  that  the  reference  (e)  reports  indi¬ 
cated  a  daily  average  of  approximately  100  IPG  II  Special  Pro¬ 
gram  requests  over  the  five  month  data  base.  If  that  count  is 
accurate ,  the  5-10  day  delay  experienced  by  these  transactions 
would  obviously  severely  hamper  NSC  San  Diego's  efforts  to 
meet  the  IPG  II  response  times  specified  in  reference  (d) . 

Keypunched  DD  1348s  and  provisions  leave  free  nodes  105 
and  109,  respectively,  for  input  to  DPD  batch  processing.  The 
DD  1348s  are  routed  to  Q-node  6  on  Figure  6-5  where  they  will 
be  processed  during  the  next  scheduled  batch  run.  Provisions 
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are  routed  to  Q-node  114  on  Figure  8-2  and  held  until  the 
next  special  1800  batch  provisions  run  occurs. 


VIII.  DATA  PROCESSING  DEPARTMENT  BATCH  PROCESSING  AND  LOTTING 


A.  DPD  FUNCTIONAL  OVERVIEW 

Figure  8-1  summarizes  the  requisition  categories  awaiting 
either  routine  or  special  batch  demand  processing  in  DPD  and 
presents  a  block  diagram  overview  of  the  events  transpiring 
during  DPD  operations.  This  figure  is  not  to  be  interpreted 
as  a  formal  part  of  the  Q-GERT  network.  It  is  provided  solely 
to  facilitate  the  explanation  of  the  DPD  functions  prior  to 
the  introduction  of  the  formal  network  symbology  in  Figure 
8-2.  Therefore,  Q-nodes  112  through  114,  which  appear  for 
the  first  time  in  Figure  8-1,  will  be  repeated  on  Figure  8-2. 

Q-node  6,  which  may  be  considered  the  routine  batch  pro¬ 
cessing  input  queue,  and  match  node  10  are  repeated  from  Figure 
6-5.  All  requisition  categories  except  QUICK  PIC,  Provisions, 
and  POE  IPG  II  requests  put  in-process  in  Customer  Services 
await  FIFO  priority  batch  processing  in  Q-node  6.  Requisitions 
will  be  released  from  Q-node  6  and  processed  when  matching 
transactions  from  the  Figure  6-5  Q-node  11  messenger  network 
are  generated.  As  previously  mentioned,  the  routine  batch 
processing  of  Q-node  6  transactions  occurs  seven  times  each 
day  with  the  first  run  scheduled  at  0330  and  the  finale  at  2200. 
Nevertheless,  the  model  routine  batch  processing  schedule  will 
consist  of  six  runs  beginning  at  0700  each  working  day  and  every 
three  hours  thereafter.  Issues  other  than  IPG  I  originated  by 
the  0330  run  will  not  be  processed  that  same  day.  Therefore, 
no  additional  issue  delay  is  being  added  by  the  revised  schedule. 


Figure  8-1 .  DPD  Functional  Overview 
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The  number  of  routine  batch  runs  was  reduced  to  six  not  only 
to  facilitate  the  network  timing,  but  also  to  circumvent  the 
somewhat  enigmatic,  and  unexplained,  scheduling  of  a  1000 
special  batch  run  right  after  a  routine  0930  effort  that  pro¬ 
cesses  available  POE  input  along  with  the  autodin  traffic. 
Finally,  it  must  be  noted  that  the  model  schedule  can  delay 
referrals  as  much  as  3.5  hours  by  virtue  of  rescheduling  the 
0330  run  until  0700. 

The  basic  functions  performed  in  DPD  are  demand  exception 
generation,  material  availability  determination,  and,  if  avail¬ 
able,  subsequent  sorting,  lotting,  and  Production  Planning 
manipulation  of  the  issue  documents  (or  issue  document  image) . 
However,  each  requisition  category  is  afforded  a  somewhat 
different  processing  technique;  Figure  8-1  illustrates  the 
functions  that  apply  to  the  various  demand  categories. 

The  SERVMART  decision  block  in  the  middle  of  the  figure 
functions  to  exclude  this  type  of  transaction  from  a  demand 
exception  check  in  accordance  with  the  rationale  presented  in 
Chapter  5.  Therefore,  SERVMART  requests  join  Provisions  and 
In-Process  demands  leaving  Q-nodes  114  and  113  in  the  block 
designated  availability  check.  The  omission  of  a  demand 
exception  check  for  Provisions  was  also  discussed  in  Chapter 
5.  In-Process  transactions  have  already  been  checked  for 
exceptions  during  Customer  Services  processing  (Figure  7-5) . 

Although  it  is  not  shown  on  the  overview,  requisitions 
having  a  demand  exception  will  be  routed  to  the  exception 
processing  unit  in  Customer  Services  where  QUICK  PICs  exceptions 
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will  be  given  expedited  processing  at  Q-node  50  (Figure  7-5) . 

All  other  batch  exceptions  will  be  given  routine,  but  priori¬ 
tized,  processing  at  Q-node  49.  The  detailed  network  symbology 
for  demand  exception  generation  is  presented  in  Figure  8-2. 

All  transactions  are  shown  being  checked  for  availability 
on  Figure  8-1.  However,  the  availability  block  is  subdivided 
into  three  distinct  applicable  rates.  SERVMART  and  Provisions 
are  assumed  to  encounter  a  net  availability  rate.  In  general, 
SERVMART  material  is  backed-up  by  main  supply  stock  in  accordance 
with  standard  SERVMART  operating  procedures.  There  are  excep¬ 
tions  to  this  policy,  but  the  model  assumption  specifies  a 
100%  back-up.  Similarly,  Provisions  requests  are  generally 
submitted  on  partially  completed  DD  1348s  that  are  prepunched 
by  NSC  San  Diego.  Therefore,  the  model  assumption  is  that  the 
prepunched  requisitions  apply  to  carried  material  only.  All 
remaining  demand  categories  except  In-Process  transactions  will 
be  referred  at  the  32%  NIS/NC  (gross)  rate  used  in  Customer 
Services  on  Figure  7-5. 

Demands  put  in-process  in  Customer  Services  are  shown  enter¬ 
ing  the  section  of  the  availability  block  labeled  probabilistic. 
This  designation  was  chosen  to  indicate  that  the  assets  that 
were  available  when  the  transaction  was  put  in-process  may  no 
longer  exist.  The  in-process  quantity  for  a  particular  line 
item  may  exceed  the  number  of  units  on-hand  at  the  1800  release 
of  these  transactions.  It  was  noted  that  transactions  are 
put  in-process  based  solely  on  the  on-hand  quantity  in  file; 
i.e.,  there  is  no  visibility  of  any  quantity  already  placed 
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in-process.  Furthermore,  the  asset  position  upon  which  the 
in-process  decision  was  based  may  have  changed  due  either  to 
the  receipt  of  additional  material  or  the  reservation  of 
assets  during  batch  processing.  The  latter  event,  of  course, 
is  most  relevant  for  attempting  to  determine  whether  sufficient 
material  remains  available  to  satisfy  the  in-process  quantity. 
Unfortunately,  any  attempt  to  estimate  a  reasonably  accurate 
availability  rate  for  the  in-process  release  procedure  would 
require  a  line  item,  vice  system,  analysis  that  is  well  beyond 
the  scope  of  this  study.  Therefore,  having  emphasized  both 
the  analytical  complexity  of  the  process  and,  more  importantly, 
the  impact  of  the  current  processing  technique  on  IPG  II 
availability  and  issue  time,  the  problem  will  conveniently  be 
ignored  by  the  model.  It  will  be  assumed  that  assets  are  still 
available  for  in-process  transactions  and,  as  illustrated  on 
Figure  8-2,  these  requests  will  not  be  subjected  to  an  availa¬ 
bility  check  at  the  time  of  release. 

The  functions  appearing  on  Figure  8-1  after  the  availability 
check  may  be  regarded  as  occurring  once  each  day  on  tihe  midnight 
shift  and  serving  to  create  and  arrange  the  issue  documents 
that  will  be  processed  the  next  morning.  Provisions  and  QUICK 
PIC  requests  are  batch  processed  during  special  runs  at  1800 
and  0100,  respectively.  The  issue  documents  for  these  categories 
are  subsequently  sorted  by  location  and  forwarded  to  the  appro¬ 
priate  warehouse  for  issue.  Other  IPG  III  requests  including 
SERVMART  replenishments  are  entered  in  a  Production  Planning 
Holding  File  and  delayed  for  one  working  day.  This  procedure 
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was  instituted  in  recognition  of  holding  area  space  constraints. 
It  proves  much  jore  efficient  to  program  an  unavoidable  24 
hour  delay  as  a  filed  issue  document  image  rather  than  an 
actual  material  issue  backlog  in  the  warehouse  and  delivery 
staging  areas. 

IPG  Ills  that  have  completed  the  programmed  delay  and  the 
remainder  of  the  non-QUICK  PIC  IPG  IIs  are  shown  entering  the 
lotting  block  on  Figure  8-1.  The  lotting  procedure  is  a  com¬ 
plex  process  that  functions  to  establish  the  issuing  sequence 
for  the  total  transaction  input.  Some,  but  by  no  means  all, 
of  the  lotting  and  issue  procedures  currently  in  effect  at 
NSC  San  Diego  may  be  summarized  in  the  following  manner: 

.  The  sorted  QUICK  PIC  transactions  are  the  first  issues 
processed  at  the  beginning  of  the  work  day. 

.  All  other  IPG  II  issue  documents  are  lotted  together 
in  the  next  LOT(s)  and  represent  the  first  new  material 
issued  after  QUICK  PIC. 

.  Any  backlogged  issues  from  the  previous  day’s  LOTS 
are  completed  prior  to  issuing  the  new  LOT  1  IPG  IIs. 

.  SERVMART  replenishments  are  a  separate  LOT  and  are 
issued  after  IPG  II  transactions  have  been  processed. 

.  Discussions  of  LOTs  and  LOT  sizes  apply  principally  to 
the  processing  of  binnable  issues  by  AMHS .  The  esti¬ 
mated  percentage  of  AMHS  issues  will  be  65%;  i.e., 

AMHS  issues  at  the  Broadway  complex  represent  65%  of 
all  NSC  San  Diego  non -Provisions  issues. 
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AMHS  accumulator  line  and  packing  line  decisions  implied 
or  made  by  the  lotting  program  are  based  on  the  number 
of  requisitions  per  customer  within  each  distinct  IPG 
LOT. 

The  LP  and  SP  packing  lines  are  generally  used  for 
large  (greater  than  124  line  items)  customers. 

The  parcel  post  packing  line  is  generally  used  for  small 
(less  than  5  line  items)  customers. 

The  OP  packing  line  is  the  "free  flow"  line  along  which 
all  non- Bearer  IPG  I  material  is  routed. 

The  remaining  ten  packing  lines  receive  material  lotted 
for  customers  to  whom  greater  than  four  but  less  than 
125  line  items  are  being  issued.  The  ten  AMHS  accumu¬ 
lator  lines,  which  are  released  one  at  a  time,  route 
material  to  the  ten  packing  lines.  A  maximum  of  ten 
customers  per  accumulator  line  is  permitted. 

A  LOT  is  considered  complete  when  the  10  accumulator 
lines  plus  the  LP  and  SP  lines  are  "filled"  by  the 
lotting  program  logic.  Therefore,  if  the  first  LOT 
does  not  cover  all  the  IPG  II  requisitions  that  must 
be  issued,  then  the  second  LOT  will  also  contain  only 
IPG  II  issue  documents.  Similarly,  two  or  three  LOTs 
may  be  necessary  to  effect  the  issue  and  subsequent 
packing/ consolidating  of  all  IPG  III  transactions. 
Referencing  a  UIC  locator/address  file,  the  lotting  pro¬ 
gram  assigns  a  local  delivery  zone  or  indicates  that 
shipping  is  required  on  the  issue  document. 


.  The  lotting  program  attempts  to  equalize  the  workload 
represented  by  each  accumulator  line  over  the  total 
number  of  LOTs  each  day. 

No  attempt  will  be  made  to  duplicate  the  logic  associated 
with  the  lotting  program.  The  basic  issue  processing  sequence 
described  above  will  be  followed,  but  no  customer-related  deci¬ 
sion  logic  will  be  included  in  the  model.  The  simulation  of 
the  packing  function,  which  will  be  described  in  Chapter  9, 
will  be  greatly  simplified  based  on  the  aforementioned  equalized 
packing  line  workload  characteristic  of  the  lotting  program. 

A  brief  comment  on  Production  Planning  should  be  made  before 
concluding  the  discussion  of  Figure  8-1.  The  model  only  recog¬ 
nizes  the  24  hour  Production  Planning  delay  of  selected  IPG 
III  issues.  In  actuality,  the  process  is  much  more  complex. 
Additional  functions  include  the  holding  of  issue  documents  for 
deployed  ships  and  an  effective  backlog  management  routine  that 
considers  daily  workload  and  local  delivery  schedules  during 
the  time-phased  release  of  backlogged  IPG  III  issues.  This 
program,  which  was  successfully  operated  in  the  past,  has  not 
been  used  recently  due  to  a  decreased  operating  tempo  and  other 
considerations . 

B.  DPD  Q-GERT  SYMBOLOGY 

Figure  8-2  depicts  the  Q-GERT  representation  of  the  DPD 
demand  processing,  sorting.  Production  Planning,  and  lotting 
functions.  Transactions  to  be  processed  arrive  at  Q-nodes  112 
through  114  and  regular  node  115,  which  is  in  the  routine  batch 
processing  stream  that  is  initiated  six  times  daily  on  Figure 
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6-5.  As  described  below,  each  network  category  will  be  pro¬ 
cessed  through  the  network  logic  on  the  upper  portion  of 
Figure  8-2  and,  where  appropriate,  result  in  a  demand  excep¬ 
tion,  a  referral,  or  occupancy  in  Q-node  126  for  sorting  and/ 
or  lotting  on  the  midnight  shift. 

The  contents  of  Q-node  6  on  Figure  6-5  will  be  routed  to 
regular  node  115  via  match  node  10  six  times  each  working  day. 
The  conditional  branching  at  node  115  routes  all  non-SERVMART 
demands  to  node  119  for  a  demand  exception  check.  The  delay 
of  0.0001  hours  on  many  of  the  Figure  8-2  branches  is  an  arbi¬ 
trarily  chosen  processing  time  that  permits  the  handling  of 
10,000  transactions  per  hour,  a  figure  that  is  well  above  the 
expected  daily  demand.  Exceptions  will  occur  at  node  119  at 
the  normal  6.2%  rate  and,  since  QUICK  PIC  does  not  arrive  at 
node  119  through  node  115,  routine  batch  exceptions  (A3.NE.3) 
will  be  routed  from  node  120  to  Q-node  49  on  Figure  7-5  for 
exception  processing.  If  no  exception  is  encountered,  the 
standard  gross  availability  check  is  made  at  node  127  with 
referrals  being  routed  to  node  65  on  Figure  7-6  and  potential 
issues  to  node  128.  The  conditional  branching  at  node  128 
functions  to  isolate  IPG  Ills  -  SERVMARTs,  Provisions,  and 
In-Process  Ills  are  excluded  -  in  order  to  assess  the  24  hour 
Production  Planning  delay  prior  to  their  entry  into  the  Sort/ 

LOT  queue.  IPG  II  transactions  are  routed  directly  to  Q-node 
126  to  await  lotting  in  a  "smallest  value  of  attribute  3"  pri¬ 
ority.  All  transactions  processed  in  DPD  are  eventually  sub¬ 
jected  to  the  Q-node  126  ranking  procedure.  Therefore,  inasmuch 
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as  I PH  I  requests  (A3  =  1  or  2)  will  theoretically  never  be 
routed  to  this  network  segment,  the  first  transactions  in 
Q-node  126  at  the  time  of  lotting  should  be  QUICK  PIC  demands. 

The  SERVMART  transactions  that  were  isolated  at  node  115 
undergo  a  different  processing  procedure.  First,  their  attri¬ 
bute  3  value  is  changed  to  4.5  at  node  129  to  ensure  position¬ 
ing  in  Q-node  126  ahead  of  all  other  IPG  III  requests.  Follow¬ 
ing  the  attribute  reassignment,  they  are  afforded  an  availa¬ 
bility  check  equal  to  the  NSC  San  Diego  all  cog  net  value  of 
83.4%  and  either  routed  to  node  65  on  Figure  7-6  for  the  collec¬ 
tion  of  statistics  on  referrals  or  forwarded  to  node  125  where, 
once  isolated  again  on  the  lower  branch,  they  are  routinely 
delayed  for  the  standard  24  hours. 

Having  completed  the  discussion  of  the  routing  of  routine 
batch  input  arriving  via  node  115,  the  QUICK  PIC  network  seg¬ 
ment  beginning  at  Q-node  112  must  be  considered.  Transactions 
shown  arriving  from  nodes  41  and  46  on  Figure  7-5  will  not 
appear  in  Q-node  112  until  after  1800  on  each  working  day; 
the  Customer  Services  QUICK  PIC  delay  network  precludes  pro¬ 
cessing  until  that  time.  Since  QUICK  PIC  requests  are  processed 
during  a  special  0100  run,  no  resources  will  be  made  available 
at  allocate  node  116  until  that  time.  The  initial  allocation 
of  1  type  5  resource  shown  on  the  RES  card  above  the  allocate 
node  was  provided  to  comply  with  the  Q-GERT  requirement  for  an 
initial  capacity  greater  than  zero;  this  resource  will  immediately 
be  removed  in  the  Chapter  10  timing  network  and  reapplied  at 
0100  on  the  appropriate  days  to  accomplish  the  sequential 
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processing  of  QUICK  PIC  transactions  in  Q-node  112.  The 
processing  rate  will  be  10,000  per  hour  as  shown  on  the  branch 
between  nodes  117  and  118,  the  free  node.  The  QUICK  PIC  trans¬ 
actions  are  routed  to  the  node  119  standard  demand  exception 
check  and,  provided  an  exception  occurs,  routed  by  the  node 
120  upper  branch  to  the  head  of  the  queue  at  Q-node  50  on 
Figure  7-5  to  ensure  QUICK  PIC  exceptions  receive  expedited 
processing  the  next  working  day.  If  no  exception  occurs,  QUICK 
PICs  are  routed  through  the  same  availability  check  and  IPG 
III  delay  network-nodes  127  and  128  -  that  routine  batch 
transactions  encounter  and  theoretically  become  positioned  at 
the  head  of  Q-node  126. 

The  special  Provisions  run  and  the  daily  reieuse  of  In- 
Process  demands  both  occur  at  1800.  The  network  resource  iogic 
associated  with  Q-nodes  114  and  113  functions  to  arbitrarily 
give  Provisions  priority;  Q-node  114  will  be  emptied  before 
any  transactions  in  Q-node  113  are  processed.  The  resource 
scheme  at  allocate  node  121  is  similar  tc  the  9nICK  rIC  log.,  r. 
The  initial  resource  6  capacity  of  1  will  immediately  b*  alt^re 
to  zero  in  the  timing  network  It  will  be  reapplied  at  19  0.. 
and  transactions  in  Q-nodes  114  and  113  will  be  processed 
a  rate  of  10,000  per  hour.  Both  this  resource  and  tne  ' U . C K 
PIC  type  5  resource  will  remain  available  for  a  haif  hour.  'he 
Customer  Services  keypunch  resource  will  be  removed  r 'em  l'r' 
to  1830  to  prohibit  the  arrival  of  In-Proce. s  transaction  dur • 
this  admittedly  extended  period.  This  technique  represents  a 
more  convenient  modeling  approach  than  a  rep'titive  sampling 


of  Q-node  contents  from  the  timing  network.  The  conditional 
branching  at  free  node  123  routes  Provisions  documents  to 
node  124  for  a  net  availability  check,  delays  the  IPG  III 
In-Process  transactions  24  hours  before  entry  to  Q-node  126, 
and  routes  IPG  II  In-Process  demands  directly  to  the  Sort/ 

LOT  queue  for  same  night  processing.  Therefore,  neither  Pro¬ 
visions  nor  In-Process  demands  are  given  a  demand  exception 
check  for  reasons  previously  discussed.  Furthermore,  In- 
Process  transactions  are  assumed  to  still  be  available  and 
Provisions  are  considered  available  at  the  same  net  rate  applied 
to  SERVMART .  This  latter  assumption  could  be  made  more  realistic 
by  using  the  availability  rate  for  Provisions  cogs  only,  but 
this  degree  of  accuracy  is  not  considered  essential  for  this 
mod  1 .  provisions  requests  leaving  node  124  are  either  referred 
through  the  branch  to  node  65  on  Figure  7-6  or  forwarded  to 
node  ..2  5  were  they  are.  conditionally  isolated  and  sent  without 
delay  to  Q-node  126  to  await  lotting  later  that  night. 

The  network  segment  beginning  with  allocate  node  130  at  the 
bottom  cf  Figure  8-2  accomplishes  as  much  of  the  actual  lotting 
procedure  as  can  conveniently  be  displayed  in  DPD.  In  particu¬ 
lar,  with  the  actual  LOTs  already  determined  by  the  ranking 
structure  in  Q-node  126,  the  sequential  processing  network 
beginning  with  node  130  serves  solely  to  effect  a  warehouse 
distribution  followed  by  the  assignment  of  the  appropriate  issue 
time  for  that  location.  Since  it's  beyond  the  scope  of  this 
project  to  consider  individual  customer  location  (shipping  or 
local  delivery)  and  percentage  of  demand,  numerous  simplifying 
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assumptions  regarding  packing  categories  and  shipping  percen¬ 
tages  will  be  made  in  Chapter  9.  This  procedure  obviously 
deviates  from  the  lotting  explanation  provided  earlier  in  this 
chapter . 

After  initially  being  altered  to  zero,  the  single  type  7 
resource  will  be  provided  at  allocate  node  130  at  0300  and 
removed  at  0500.  Unless  there  are  more  than  20,000  transac¬ 
tions  waiting  in  Q-node  126,  which  is  highly  unlikely,  the 
two  hours  will  be  sufficient  to  empty  the  Sort/LOT  queue.  At 
free  node  132  all  Provisions  requests  are  branched  directly 
to  node  135  for  a  National  City  issue  time  assignment  to 
attribute  5,  then  sent  to  node  138  to  be  isolated  once  again 
and  forwarded  to  a  specific  National  City  queue.  All  other 
National  City  issues  arriving  at  node  138  are  forwarded  to  a 
different  queue  to  distinguish  them  from  the  Provisions  demands 
in  the  issue  processing  priority  scheme  shown  in  Chapter  9. 

The  middle  branch  from  node  132  routes  SERVMART  requests  to 
node  133  for  the  indicated  probabilistic  division  into  Broadway 
and  National  City  issues,  the  assignment  of  appropriate  issue 
times,  and  further  routing  as  shown.  The  bottom  branch  from 
free  node  132  to  node  139,  which  routes  all  transactions  other 

than  SERVMART  and  Provisions,  permits  a  "precautionary  check" 

% 

for  IPG  I  transactions  at  node  139  prior  to  the  indicated 
routing  to  node  134  for  the  standard  non-Provisions  issue  branch¬ 
ing  of  65%  Broadway  bin,  20%  Broadway  bulk,  and  15%  National 
City  that  was  first  encountered  on  Figure  7-6.  The  bottom 
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branch  from  node  139  routes  IPG  Is  that  have  inadvertently 
been  subjected  to  DPD  processing  back  to  the  IPG  I  processing 
stream  on  Figure  7-5.  As  a  final  comment,  it  should  be  noted 
that  the  Broadway  bin  issue  time  of  0.045  hours  assigned  at 
node  136  is  significantly  less  than  the  0.068  hours  allotted 
to  IPG  Is  at  node  77  on  Figure  7-6.  The  difference  lies  in 
the  faster  sequential  processing  of  lotted  bin  issues  using 
the  AMHS  capability  in  lieu  of  the  IPG  I  unsequenced  hotline 
issue  procedure  that  acts  as  an  interrupt  to  ongoing  processing. 


IX.  ISSUE,  PACKING,  MARKING,  AND  LOCAL  DELIVERY 

A.  DATA  CONSIDERATIONS 

The  Broadway  and  National  City  issue,  packing,  and  marking 
functions  and  the  local  delivery  system  are  presented  on  Figures 
9-1  through  9-4.  Distinct  network  segments  are  provided  for 
Broadway  bin,  Broadway  bulk,  and  National  City.  The  system 
displayed  generally  approximates  operating  procedures  in  effect 
in  May  1980.  However,  procedural  changes  within  the  next  few 
months  are  a  virtual  certainty.  Therefore,  the  contemplated 
revisions  are  discussed  in  the  last  section  of  this  chapter. 

The  processing  times  as  well  as  the  percentage  estimates 
dictating  the  numerous  probabilistic  branches  used  in  the  model 
are  of  dubious  validity.  The  DIMES  issue  times  assigned  to 
the  transactions  on  Figure  8-2  were  not  disputed.  However, 
both  the  Broadway  and  National  City  packing  supervisors  took 
exception  to  the  packing  standards  established  by  the  DIMES 
study  and  used  in  the  reference  (b)  simulation.  Therefore, 
revised  standards  based  upon  the  supervisor's  estimates  were 
used  fro  packing  and  marking.  Having  observed  the  bulk  packing 
operation,  it  appears  much  more  realistic  to  use  the  updated 
version.  The  DIMES  standard  of  8.5  bulk  light  packs  per  hour  is 
not  nearly  as  realistic  as  the  2.15  line  items/hour  used  to 
gauge  the  National  City  packers'  performance.  Marking  times 
for  bulk  material  going  to  shipping  were  also  revised  to  reflect 
10.5  line  items  per  hour,  or  .095  hours  per  item,  vice  the 


120 


. ^ 

variable  marking  time  scheme  used  in  reference  (b) .  Marking 
light  and  heavy  packs  is  identical  except  for  the  size  of 
the  container  being  marked. 

The  difficulty  in  developing  accurate  branching  percentage 
stems  from  the  lack  of  line  item  work  measurement  statistics 
in  the  Material  Department.  Due  to  the  degree  of  consolidation 
occurring  in  the  packing  process  and  the  excessive  bulk  of 
much  of  the  material  that  must  be  processed,  the  predominant 
work  unit  becomes  measurement  tons.  Therefore,  although 
information  such  as  the  number  of  measurement  tons  packed  or 
sent  to  shipping  is  readily  available,  the  percentage  of  line 
items  receiving  a  particular  kind  of  pack  or  requiring  shipping 
remains  a  crude  estimate  at  best.  The  same  rationale  applies 
to  the  distinction  between  light  and  heavy  pack;  the  decision 
is  based  upon  the  volume  of  the  container  that  must  be  processed. 

Neither  line  item  volume  nor  a  completely  accurate  representa¬ 
tion  of  the  impact  of  line  item  consolidation  can  be  modeled. 

In  fact,  the  effects  of  consolidation  on  bulk  material  are 
deliberately  ignored  during  initial  model  formulation.  Every 
bulk  line  item  routed  to  packing  at  Broadway  or  National  City 
is  assigned  a  pack  time.  The  rationale  for  this  decision  is 
presented  during  discussion  of  relevant  Q-GERT  network  segments. 
Consolidation  is  a  major  factor  in  binnable  item  processing, 
however,  and  a  detailed  discussion  of  this  concept  is  included 
in  Section  9C. 

Finally,  the  issue  documents  generated  during  the  lotting 
process  are  picked  up  each  morning  and  distributed  to  the 
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appropriate  warehouse  by  the  beginning  of  the  day  shift.  The 
model  does  not  simulate  that  messenger  service.  Transactions 
leaving  DPD  are  routed  directly  to  the  appropriate  issue  queue. 
This  technique  introduces  no  error  into  the  model.  Although 
the  transactions  arrive  at  the  Q-nodes  prematurely,  no  resources 
are  made  available  to  process  them  until  the  day  shift  commences. 

B.  BROADWAY  BULK  MATERIAL  PROCESSING 

The  complete  Broadway  bulk  issue,  packing,  and  marking 
process  is  displayed  on  Figure  9-1.  The  bulk  input  is  shown 
arriving  at  Q-nodes  142  and  143  in  the  upper  left  portion  of 
the  figure.  Q-node  142  contains  only  IPG  I  issue  documents. 
Bearers  arrive  via  node  97  from  Figure  7-6  and,  by  virtue  of 
an  attribute  3  value  of  1,  assume  a  position  at  the  head  of 
the  S/3  (smallest  value  of  attribute  3)  queue.  The  other  IPG 
I  issue  documents,  which  are  transported  by  messenger  from  node 
92  on  Figure  7-6,  are  routed  to  the  queue  from  node  141.  The 
conditional  branching  at  that  node  separates  the  bulk  issues 
from  the  bin  issues  that  are  carried  to  a  different  location 
by  the  same  messenger.  The  0.2  hour  delay  on  the  branch  between 
nodes  141  and  142  is  additive  to  the  0.4  hour  document  delay 
on  Figure  7-6  and  models  the  depositing  of  bin  IPG  I  issue 
documents  0.2  of  an  hour  before  the  bulk  DD  1348-ls.  The 
lotted  output  of  Broadway  bulk  material,  which  contains  only 
IPH  II  and  III  issues,  is  shown  entering  Q-node  143  from  node 
137  on  Figure  8-2.  Although  a  given  day's  lotting  output  will 
arrive  at  node  143  in  IPG  sequence,  the  F  (First-In-First-Out) 
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ranking  procedure  will  ensure  that  backlogged  issues  are 
processed  before  the  higher  priority  transactions  lotted 
the  following  day.  Of  course,  IPG  Is  will  always  take  prece¬ 
dence  through  being  routed  to  the  preferred  queue,  Q-node  142. 

Nodes  144  though  146  represent  the  resource  allocation 
network  that  performs  the  bulk  issue.  The  RES  card  image  above 
allocate  node  144  indicates  that  27  warehousemen  are  available 
each  working  day  to  make  bulk  issues.  The  RES  card  also  indi¬ 
cates  that  this  type  9  resource  may  only  be  allocated  at  node 
144.  The  issue  processing  time,  which  was  assigned  as  attri¬ 
bute  5  on  Figures  7-6  and  8-2,  is  shown  on  the  branch  between 
node  145  and  free  node  146.  Note  that  the  free  node  has  no 
allocate  scheme  beneath  it.  Therefore,  the  RES  card  order, 
node  144  only,  prevails.  In  fact,  throughout  this  chapter 
resources  will  generally  be  associated  with  a  single  allocate 
node  and  changes  in  capacity  or  the  shifting  of  resources  will 
have  to  be  accomplished  either  through  changes  to  the  RES 
card(s)  or  alteration  schemes  similar  to  the  issue/receipt 
example  presented  in  Chapter  7.  One  type  9  resource  will 
remain  available  for  the  second  shift  to  ensure  that  IPG  Is 
are  processed.  However,  since  the  contents  of  Q-node  143 
are  also  processed  by  the  same  resource,  lower  IPG  backlog 
will  also  be  issued  and  subsequently  packed  and/or  marked 
during  the  evening  shift.  Similarly,  an  issue  and  packing 
resource  will  remain  at  Broadway  bin  and  National  City  to 
guarantee  that  IPG  Is  are  afforded  the  necessary  expeditious 
treatment.  The  issue  backlog  processing  feature  at  all  three 
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locations  is  not  representative  of  actual  operations.  A 
Broadway  issuer  and  packer  are  available  for  IPG  I  processing 
throughout  the  Broadway  complex  and  backlog  management  as 
time  permits.  Modeling  that  procedure  would  require  either 
distinct  resource  categorizations  and  allocate  nodes  for  IPG 
I  processors  (see  AMHS  packing  on  Figure  9-2)  or  a  separate 
evening  shift  model  that  would  replace  the  existing  network 
segments  at  1600.  Such  complexity  was  not  considered  necessary. 
The  network  presented  represents  a  satisfactory  starting  point. 

If  initial  runs  yield  a  high  percentage  of  idle  resources, 
there  are  numerous  alternatives  that  could  be  evaluated.  For 
example,  simulation  time  could  be  used  to  compute  the  shift 
on  which  an  IPG  I  arrives  and  effect  a  routing  to  a  special 
queue  for  second  shift  processing.  This  approach  would  be 
used  in  place  of  the  retention  of  a  second  shift  resource  and 
eliminate  the  processing  of  lower  priority  backlog  by  focusing 
only  on  IPG  Is  after  1600. 

After  the  resource  is  freed  at  node  146,  the  probabilistic 
branching  designed  to  model  warehouse  refusals  is  encountered. 

The  1%  branch  leaving  node  146  serves  to  route  warehouse  refusals 
to  Q-node  154  where  they  await  the  arrival  of  the  messenger 
from  node  94  on  Figure  7-6.  The  messenger  network  modeled  by 
nodes  152  through  158  is  basically  identical  to  the  similar 
segment  described  in  detail  in  Chapter  5.  The  second  input 
into  Q-node  154  represents  Broadway  bin  warehouse  refusals. 
Although  they  are  picked  up  at  a  different  location,  it  is 
assumed  that  they  accompany  the  messenger  on  the  0.2  hour 
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journey  from  the  bin  area  to  the  bulk  warehouse.  Therefore, 
a  single  queue  representation  of  warehouse  refusal  routing  to 
Customer  Services  node  50  is  realistic.  Two  differences  from 
the  Chapter  6  network  segment  are  worthy  of  mention:  (1)  the 
warehouse  refusals  are  assigned  an  attribute  3  value  of  0  at 
node  157  to  establish  processing  priorities  on  Figure  7-5; 
and  (2)  the  messenger  is  not  routed  from  node  158  since  this 
network  segment  represents  the  last  stop  on  his  modeled  run 
and  each  run  is  initiated  from  the  timing  network.  Therefore, 
the  messenger  run  time  totals  1.9  hours  consisting  of  0.5  hours 
on  Figure  6-5  (node  85),  0.8  hours  on  Figure  6-6  (node  87), 
and  0.6  hours  on  Figure  7-6  (node  94).  The  document  delay  of 
0.4  hours  leaving  node  92  on  Figure  7-6  represents  travel  time 
to  the  Broadway  bin  issue  area.  An  additional  0.2  hours  is 
assessed  bulk  issues  on  Figure  9-1. 

The  transactions  routed  along  the  upper  branch  leaving 
node  146  represent  material  issues.  At  node  159  Bearers  are 
removed  from  the  system  as  completed  issues  and  routed  to 
Figure  9-4  for  issue  statistics  formulation;  NSC  San  Diego 
has  no  further  processing  responsibility  for  Bearers  once  the 
material  has  been  turned  over  to  the  representative  of  the 
requesting  activity.  However,  bulk  issues  for  both  SERVMART 
and  QUICK  PIC  transactions  are  also  factored  out  as  completed 
issues  at  node  159.  QUICK  PICs  are  isolated  for  transportation 
to  the  National  City  designated  customer  pick-up  point.  It 
was  not  considered  necessary  to  model  that  segment  of  the 
QUICK  PIC  procedure.  The  statistics  collected  on  Figure  9-4 
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are  just  as  meaningful  without  the  travel  time  to  National 
City.  SERVMART  transactions  are  removed  and  sent  to  SERVMART 
Central  Receiving  where  they  undergo  further  processing  to 
ensure  compatability  with  the  EPOS  inventory  system.  The 
same  procedure  is  followed  for  Broadway  bin  SERVMART  issues. 
However,  National  City  SERVMART  issues,  which  constitute  only 
5%  of  the  total,  are  staged  in  local  delivery  and  transported 
to  the  appropriate  zone  as  shown  on  Figure  9-3.  The  bottom 
branch  leaving  node  159  directs  all  other  transactions  to 
node  161  in  the  lower  left  portion  of  the  figure. 

The  shipping/local  delivery  probabilistic  branching  occurs 
at  node  161  with  80%  of  the  transactions  designated  local 
delivery  and  routed  to  node  199  where  IPG  Is  ( non-Bear eres) 
are  terminated.  Admittedly,  indicating  an  issue  completion  at 
that  juncture  appears  premature.  However,  local  delivery  IPG 
Is  are  not  staged  to  await  scheduled  zone  transportation;  nor 
are  they  routed  through  any  packing  or  marking  evolutions. 

They  are,  however,  considered  individually  and  delivered  by 
the  most  expedient  available  method.  A  more  sophisticated 
study  might  consider  the  time  of  day  and  next  scheduled  delivery 
to  the  designated  zone  to  facilitate  the  assignment  of  a  more 
realistic  issue  completion  time.  However,  meeting  IPG  I  time 
frames  has  not  been  a  problem  at  NSC  San  Diego.  Therefore, 
only  the  standard  two  hour  delay  assigned  as  representative 
of  the  time  between  trips  to  local  delivery  staging  has  been 
acknowledged  in  the  model.  The  similar  delay  for  IPG  II  and 
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Ill  local  delivery  material  is  shown  on  Figure  9-2  immediately 
preceding  the  bottom  branch  into  node  191.  The  bypassing  of 
packing  and  marking  for  local  delivery  bulk  will  apply  to 
National  City  material  as  well.  Only  bulk  material  destined 
for  shipping  will  undergo  the  packing  evolution. 

Broadway  bulk  material  to  be  shipped  represents  20%  of 
the  output  from  node  161.  After  being  delayed  one  hour  to 
roughly  model  transportation  to  the  packing  area,  material  to 
be  packed  arrives  at  node  198  where  IPG  Is  are  segregated  and 
sent  to  Q-node  162  to  ensure  they  receive  preferred  order 
processing  by  the  resources  allocated  at  node  164.  Material 
that  has  been  allotted  type  11  resources  is  probabilistically 
routed  to  node  166  (40%),  node  167  (35%),  or  node  200  (25%)  for 
an  attribute  6  assignment  representing  the  indicated  category 
of  pack  plus  mark  time.  The  type  11  resource  capacity  includes 
packers  plus  markers  although  the  functions  are  generally  per¬ 
formed  independently  with  marking  as  a  separate  station  follow¬ 
ing  packing.  However,  since  marking  backlogs  are  a  rarity, 
a  first  pass  should  be  attempted  with  the  functions  combined. 
Since  there  is  no  mark  standard  associated  with  parcel  post 
and  light  pack  is  marked  approximately  five  times  as  fast  as 
it's  packed,  a  distinct  marking  resource  would  be  idle  over 
95%  of  the  time.  A  separate  resource  allocation  network  for 
the  marking  function  can  always  be  added  between  free  node 
169  -  revised  to  provide  a  conditional  branching  that  sends 
only  light  and  heavy  pack  to  marking  -  and  the  branching  to 
issue  statistics  collection.  The  conditional  branching  from 
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node  169  on  Figure  9-1  segregates  IPG  I  material  from  all 
other  categories  and  effectively  completes  the  issue  of  packed 
and  marked  material  sent  to  shipping.  The  packing  and  marking 
standards  applicable  to  Broadway  bulk  are  included  on  Figure 
9-1  for  ease  of  reference. 

The  branching  from  node  169  to  the  Figure  9-4  statistics 
collection  network  represents  the  completion  of  requisition 
processing  by  the  model  for  items  destined  for  shipping. 

However,  the  time  being  measured  must  not  be  interpreted  as 
representative  of  the  complete  requisition  processing  sequence 
at  NSC  San  Diego.  Items  exiting  node  169  actually  are  staged 
for  periodic  delivery  to  shipping,  which  is  located  in  National 
City.  The  subsequent  events  occurring  in  shipping  constitute 
a  requisition  response  time  segment  called  Transportation  Hold 
.Time.  This  period,  which  includes  functions  such  as  selection 
of  a  shipping  mode  and  consolidation  of  IPG  III  material  for 
specific  transportation  categories,  will  not  be  modeled  during 
this  study.  Therefore,  the  statistics  collected  for  material 
sent  to  shipping  are  an  estimate  of  the  response  time  segment 
called  Storage  Site  Processing  Time.  Of  course,  the  model 
could  be  expanded  to  include  the  shipping  function  and  trans¬ 
actions  leaving  node  169,  and  similar  nodes  on  Figures  9-2  and 
9-3,  could  be  routed  for  additional  processing.  The  model's 
treatment  of  local  delivery  material  includes  the  Transportation 
Hold  segment. 
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C.  BROADWAY  BIN  MATERIAL  PROCESSING 


Bin  material  processing  is  illustrated  on  Figures  9-1  and 
9-2.  The  routing  through  the  bin  issue  process  on  Figure  9-1 
is  basically  identical  to  the  Broadway  bulk  issue  process. 

IPG  Is  are  routed  to  node  147  and  all  batch  transactions  are 
shown  arriving  from  node  136  on  Figure  8-2.  The  resource 
allocation  network  consisting  of  nodes  149  through  151  pro¬ 
cesses  the  contents  of  Q-node  147  (IPG  Is)  before  transactions 
in  node  148.  The  issue  time  is  again  the  transaction  attribute 
5  value,  which  was  assigned  during  the  lotting  procedure  in 
Chapter  8  or  on  Figure  7-6  for  IPG  I  requests.  The  FIFO  ranking 
in  Q-node  148  will  ensure  that  backlog  is  processed  before 
newly  lotted  transactions.  Warehouse  refusals  are  originated 
at  free  node  151  and  routed  to  the  messenger  network  described 
in  the  Broadway  bulk  discussion.  Finally,  QUICK  PIC,  SERVMART, 
and  Bearer  issues  depart  the  system  at  node  160.  The  rationale 
for  this  decision  was  also  presented  in  the  discussion  of  bulk 
issues . 

A  few  additional  comments  on  the  bin  issue  time  are  appro¬ 
priate.  First,  IPG  I  issues,  which  represent  an  interrupt 
to  sequential  location  processing,  are  assigned  a  larger 
issue  time  than  lotted  transactions.  Secondly,  the  lotted  line 
item  issue  time,  while  being  lower  than  the  IPG  I  value,  includes 
an  average  UIC  sort  time.  Lotted  material  is  picked  in  loca¬ 
tion  sequence  then  manually  consolidated  by  UIC  on  a  spar  line 
before  the  tote  pans  holding  the  binnable  material  are  forwarded 
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to  packing  via  the  AMHS  accumulator  lines.  An  awareness  of 
this  procedure  is  crucial  to  the  discussion  of  the  several 
posed  procedural  changes  presented  at  the  end  of  this  section. 
Finally,  consideration  was  given  to  assigning  the  higher  IPG 
I  issue  time  to  QUICK  PIC  transactions.  Their  relatively  low 
volume  would  appear  to  negate  the  benefits  of  the  location  sort 
they  are  given;  i.e.,  there  would  still  be  a  considerable  dis¬ 
tance  between  locations.  However,  since  they  are  not  subjected 
to  the  UIC  sort  that  is  included  in  the  AMHS  bin  issue  time, 
it  was  concluded  that  the  faster  time  was  more  representative. 

The  remaining  transactions  departing  node  160  are  routed 
to  node  171  on  Figure  9-2  for  IPG  I  segregation  and  application 
to  the  bin  packing  and  marking  network  beginning  with  Q-nodes 
172  and  179.  At  this  juncture  the  current  bin  processing  pro¬ 
cedure  differs  from  the  bulk  branching  logic;  all  bin  material, 
destined  for  both  local  delivery  and  shipping,  goes  through 
packing.  Therefore,  a  probabilistic  branch  analagous  to  the 
node  161  (Figure  9-1)  routing  to  local  delivery  is  not  required 
for  bin  material.  All  remaining  IPG  Is  are  branched  to  Q-node 
172  on  Figure  9-2  and  all  other  transactions  are  routed  to 
Q-node  179. 

The  Broadway  bin  packing  and  marking  network  contains  two 
distinct  resource  types.  The  solitary  type  12  resource  allo¬ 
cated  only  at  node  173  models  the  OP  line  along  which  all  IPG 
Is  are  routed.  This  resource  will  remain  available  on  the 
evening  shift.  However,  since  reallocation  occurs  only  to 
node  173,  the  lower  priority  bin  backlog  in  Q-node  179  will 
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Figure  9-2.  Broadway  Bin  P-ack/Mark  and  Local  Delivery  Staging 


not  be  packed  and  marked  during  the  second  shift.  It  was 
considered  necessary  to  associate  a  distinct  allocate  node 
with  IPG  I  transactions.  Using  the  bulk  packing  procedure 
of  a  simple  allocate  node,  14  resources,  and  the  IPG  I  queue 
designated  as  preferred  would  lead  to  situations  where  all 
14  packers  were  processing  IPG  Is.  Such  an  occurrence  would 
be  a  complete  distortion  of  reality;  each  of  the  14  packers 
is  assigned  to  a  specific  packing  line  and  the  lotting  program 
attempts  to  equalize  workload  along  10  of  these  lines  at  least. 
The  large  customer  lines,  SP  and  LP,  and  the  Parcel  Post  line 
receive  material  based  on  specific  criteria  that  preclude  work¬ 
load  equalization.  Consideration  was  given  to  having  the  IPG 
I  resource  work  secondarily  on  the  contents  of  Q-node  179  in 
a  manner  similar  to  the  Q-node  110  relationship  to  allocate 
node  103  on  Figure  7-7  (envision  a  second  dashed  line  originated 
at  Q-node  179  and  terminated  at  allocate  node  173) .  This  idea 
was  discarded  based  on  a  reluctance  to  apply  IPG  I  material 
for  binnable  items  will  theoretically  be  packed  on  a  line  item 
basis  most  of  the  time.  Therefore,  the  packing  times  assigned 
should  require  little  or  no  adjustment  to  incorporate  the 
effects  of  packing  numerous  line  items  for  the  same  customer 
in  the  same  container.  On  the  other  hand,  the  material  on 
every  other  line  but  Parcel  Post  is  grouped  by  UIC  and  is 
afforded  a  packing  standard  that  differs  from  the  time  associated 
with  individual  line  item  packing.  Therefore,  no  attempt  was 
made  to  model  the  IPG  I  packers  involvement  with  material  on 
other  lines  when  Q-node  173  is  empty.  However,  providing  an 


133 


example  of  how  such  a  procedure  could  be  modeled  will  illus¬ 
trate  a  useful  method  of  using  dissimilar  resources  to  perform 
the  same  function. 

The  single  digit  numbers  in  the  network  above  were  added 
to  the  Figure  9-2  decision  logic  and  free  node  190  was  modi¬ 
fied  to  release  either  type  12  or  13  resources  based  on  the 
attribute  7  value  of  the  arriving  transaction.  All  transactions 
arriving  at  node  3  from  Q-node  179  will  use  type  13  resources. 
Therefore,  an  attribute  7  value  of  13  is  assigned  to  all  trans¬ 
actions  that  are  allocated  resources  by  node  180.  Allocate 
node  173,  however,  is  modeled  to  enable  processing  of  transac¬ 
tions  from  Q-node  179  must  be  subjected  to  the  branching  deci¬ 
sions  beginning  at  node  182.  Therefore,  for  an  IPG  II  or  III 
item,  the  lower  branch  is  taken  from  node  1  and  an  attribute 
7  value  of  12  is  assigned  at  node  2  before  the  transaction  is 
processed  at  node  182  and  beyond.  Arrival  of  the  transaction 
at  free  node  190  will  then  result  in  the  correct  type  of  re¬ 
source  being  released.  The  objective  of  this  example  was  to 
illustrate  that  free  nodes  need  not  be  restrictive  in  the  type 
of  resources  that  they  may  release.  It  should  be  noted  that 
free  nodes  such  as  178  and  190  on  Figure  9-2  will  release 
only  the  designated  type  12  and  13  resources,  respectively. 

Prior  to  completing  the  discussion  of  the  Figure  9-2  net¬ 
work  segment,  the  issue  of  consolidation  and  the  rationale 
for  the  packing  standards  used  for  bin  material  must  be 
addressed.  The  consolidation  standard  used  in  reference  (b) , 
which  appears  to  have  been  applied  to  both  bin  and  bulk  items, 
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was  3.46  L/I  (line  items)  per  pack.  This  consolidation  factor 
was  used  in  conjunction  with  DIMES  packing  standards  which, 
based  on  more  recent  observed  production  rates,  appear  to  be 
too  low.  There  is  some  bulk  consolidation  undertaken  at  National 
City,  particularly  with  IPG  III  material.  Nevertheless,  a 
3.46  L/I  per  pack  average  is  considered  too  high  to  be  repre¬ 
sentative  of  actual  National  City  operations.  A  higher  degree 
of  consolidation  is  realized  for  Broadway  bulk  material  and, 
consequently,  the  3.46  average  may  be  realistic.  If  initial 
simulation  runs  create  excessive  backlogs  using  the  Figure  9-1 
individual  line  item  bulk  packing  procedure,  then  the  consoli¬ 
dation  feature  can  be  modeled  by  creating  a  new  mark  plus  pack 
time  equal  to  the  current  value  divided  by  the  average  number 
of  line  items  per  pack.  It  would  appear  prudent  to  initially 
simulate  with  a  few  values  somewhat  lower  than  3.46. 

The  Broadway  bin  consolidation  factor  is  assuredly  higher 
than  the  3.46  L/I  value.  Twelve  of  the  fourteen  packing  lines 
theoretically  receive  material  grouped  by  UIC  with  at  least 
five  line  items  per  customer.  It  follows  that  the  majority 
of  the  material  on  these  12  lines  would  be  consolidated  at  a 
rate  of  at  least  five  line  items  per  pack.  In  fact,  two  of 
these  twelve  lines,  LP  and  SP,  will  often  contain  over  200 
line  items  for  the  same  customer.  Therefore,  a  consolidation 
factor  limited  only  by  the  size  of  the  container  and/or  subse¬ 
quent  transportation  weight  or  volume  constraints  will  apply. 

In  view  of  the  emphasis  on  consolidated  packing  of  binnables, 
an  admittedly  rough  approach  for  incorporating  consolidation 
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into  the  initial  model  was  developed  and  is  presented  during 
the  discussion  of  the  actual  standards  below. 

The  bin  material  packing  categories  may  be  summarized 
and  modified  in  the  following  manner: 


CATEGORY 

PACK/HR 

STANDARD 

HR/PACK 

MODELED 

L/I  PER  PACK 

STANDARS 
HR/LINE  ITEM 

Parcel  Post 

12.42/hr. 

0.08 

1 

0.08 

Rough  Pack 

14.59/hr. 

0.068 

7.6 

0.009 

(Local  Delivery) 

Light  Pack 

2.15/hr. 

0.465 

7.6 

0.07 

(Shipping) 

Heavy  Pack 

0 . 7/hr . 

1.43 

15.2 

0.103 

(Shipping) 

Column  three  is 

simply  the 

reciprocal 

of  column  two 

.  It  is 

displayed  to  provide  a  correlation  with  the  processing  time 
value  assignments  that  are  entered  on  the  relevant  network 
figures  in  terms  of  "standard"  hours.  The  pack/hour  standards 
were  supplied  by  the  NSC  San  Diego  packing  supervisors  at 
Broadway  and  National  City.  Excluding  IPG  Is  on  the  OP  line 
and  material  on  the  parcel  post  line,  all  Broadway  bin  material 
can  be  viewed  as  receiving  an  initial  rough  pack  consisting 
of  the  placing  of  all  material  for  a  particular  UIC  in  a  large 
container ( s) .  Local  delivery  material  would  then  receive 
negligible  additional  packing  time  and  a  relatively  fast  mark¬ 
ing  process.  To  the  contrary,  rough  packed  material  destined 
for  shipping  would  encounter  significant  additional  packing 
time.  The  container  would  receive  a  light  pack  if  its  volume 
were  less  than  20  cubic  feet  or  a  heavy  pack  if  larger. 
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The  modeled  L/I  per  pack  values  in  column  4  were  computed 


based  upon  the  following  assumptions:  (1)  the  column  two 
pack/hour  is  accurate;  and  (2)  an  arbitrary  time  of  0.5  minutes, 
or  0.009  standard  hours  as  shown  in  the  last  column  for  rough 
pack,  is  needed  to  physically  verify  the  UIC  on  a  binnable 
item  and  place  it  in  the  appropriate  container.  Consequently, 
since  it  takes  0.068  hours  to  complete  one  rough  pack,  there 
are  7.6  L/I  (0.068  7  0.009)  in  each  rough  pack.  The  heavy 
pack  modeled  L/I  per  pack  was  arbitrarily  set  to  twice  the 
light  pack  value  in  recognition  of  the  larger  volume. 

The  standard  hours/line  item  for  material  sent  to  shipping 
will  be  larger  to  reflect  the  actual  packing  evolution  after 
the  indicated  number  of  line  items  are  containerized.  For 
the  purposes  of  the  initial  runs  of  this  model,  the  entire 
column  three  standard  hour  per  pack  value  will  be  divided  among 
the  indicated  number  of  line  items  per  pack.  Therefore,  a 
light  pack  line  item  will  be  assessed  an  initial  0.009  hours 
plus  its  share  of  the  0.465  hours  per  light  pack.  The  light 
pack  hour  per  line  item  becomes  0.009  hours  plus  0.465  7.6 

hours,  or  0.009  plus  .061,  which  is  0.07  hours.  Based  on  the 
results  of  initial  simulations,  the  modeler  may  wish  to  reduce 
the  additional  light  pack  assessment  per  line  item  to  cover 
only  the  difference  between  the  0.465  hour  per  pack  and  the 
containerization  time  (0.009  x  7.6)  .  Using  this  approach,  0.397 
hours  of  light  pack  time,  or  0.052  hours  per  line  item,  would 
be  allocated  across  7.6  line  items.  Then  a  total  pack  time 
of  the  standard  0.465  hours  consisting  of  containerization 
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time  (0.009  x7.6)  plus  light  pack  time  (0.052  *7.6)  would  be 
realized.  The  technique  currently  used  yields  a  total  light 
pack  time  of  0.532  hours  because  the  containerization  time 
is  additive  to  the  total  standard  pack  time. 

The  heavy  pack  time  per  line  item  is  computed  in  a  simi¬ 
lar  manner  with  the  entire  1.43  hours  per  pack  spread  across 
the  15.2  line  items  per  pack.  Therefore,  each  line  item  will 
receive  a  0.009  containerization  time  plus  a  0.094  hour  (1.43 
-7  15.2)  additive  heavy  pack  time  for  a  total  of  0.103  hours. 
Once  again  the  total  heavy  pack  time  will  exceed  the  column 
three  standard  by  the  amount  of  time  necessary  to  containerize 
the  15.2  line  items. 

The  mark  time  standard  of  10.5  packs  per  hour,  or  0.095 
hours,  will  also  be  distributed  across  the  modeled  line  items 
per  pack  for  items  going  to  shipping. 

Packing  estimates  in  general,  and  this  attempt  to  model 
the  impact  of  binnable  consolidation  in  particular,  must  be 
scrutinized,  evaluated,  and  revised  as  needed.  Although  the 
rough  pack  standard  is  probably  relatively  accurate,  the  light 
and  heavy  pack  estimates  contain  a  significant  amount  of  varia¬ 
bility.  Bulk  packing  estimates,  which  initially  contain  no 
consolidation  feature,  are  exceptionally  variable;  the  values 
specified  represent  an  average  of  pack  times  that  occasionally 
exceed  eight  hours. 

To  summarize,  bulk  material  packing  times  are  not  adjusted 
for  the  impact  of  consolidation;  items  to  be  shipped  are  packed 
on  a  line  item  basis  and  local  delivery  bulk  material  bypasses 


packing.  Unrealistic  bulk  packing  backlogs  encountered  in 
early  simulation  runs  should  first  be  addressed  by  incorporating 
a  consolidation  factor  similar  to  the  binnable  approach.  The 
binnable  packing  model,  which  is  explained  on  a  node-by-node 
basis  below,  represents  the  most  reasonable  initial  approach 
available  given  the  paucity  of  line  item  data.  It  should  be 
emphasized  that  the  accumulation  technique  described  in  Chapter 
4  could  be  used  to  great  advantage  in  any  consolidation  scheme 
if  it  were  not  necessary  to  maintain  line  item  visibility. 
However,  line  item  tracking  is  necessary  for  the  computation 
of  relevant  processing  statistics.  The  accumulation  method 
is  therefore  unacceptable. 

Returning  to  Figure  9-2,  consider  the  network  segment  de¬ 
voted  to  the  packing  and  marking  of  the  IPG  I  material  residing 
in  Q-node  172.  When  the  solitary  IPG  packing  resource  becomes 
available,  one  IPG  I  binnable  line  item  is  released  from  Q-node 
172  and  subjected  to  the  probabilistic  branching  at  node  174. 

If  the  item  must  be  shipped  to  a  remote  customer,  the  indicated 
0.08  mark  plus  pack  time  is  assigned  to  attribute  6  of  the 
transaction  at  node  175.  Although  this  value  is  equal  to  the 
binnable  parcel  post  packing  standard  (which  includes  marking) , 
it  is  not  meant  to  indicate  that  all  shipped  IPG  Is  will  be 
mailed.  It  is  simply  reasonable  to  assume  that  a  line  item 
of  binnable  material  being  prepared  for  shipment  would  be 
packaged  in  a  manner  similar  to  parcel  post.  It  appears  realis¬ 
tic  to  assume  that  line  item  quantities  for  IPG  Is  are  not 
excessive  and  therefore  are  not  subjected  to  a  light  pack  rate 
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of  0.465  hours.  Therefore,  with  the  line  item  quantities 
small  and  consolidation  ignored,  a  packing  rate  similar  to 
parcel  post  seemed  appropriate.  Once  again,  if  on-site  evalua¬ 
tion  indicates  that  IPG  consolidation  should  be  considered, 
the  network  segment  should  be  modified.  Although  a  batch  input 
of  IPG  Is  by  a  Fleet  unit  should  be  rare,  it  is  probable 
that  shore  customers,  particularly  Naval  Shipyard  Long  Beach, 
will  occasionally  originate  multiple  high  priority  requests. 

The  80%  of  the  IPG  I  local  delivery  material  that  is  routed 
to  node  176  is  assigned  a  mark  plus  pack  time  of  0.05  hours. 

This  value  is  arbitrary,  but  allowing  three  minutes  to  place 
a  small  item  in  a  box  or  envelope  and  affixing  the  address 
portion  of  the  DD  1348-1  seems  adequate.  Having  assigned 
the  appropriate  pack  plus  mark  time  to  attribute  6  of  each 
IPG,  the  actual  time  is  expended  between  nodes  177  and  178. 

The  packing  and  marking  completed,  the  resource  is  freed  at 
node  178  and  the  issue  is  considered  complete  with  the  routing 
of  the  transaction  to  Figure  9-4  for  the  collection  of  statistics. 

The  processing  of  the  lower  priority  material  on  the  other 
13  packing  lines  is  somewhat  more  complex.  First,  parcel  post 
line  material,  which  is  processed  on  a  line  item  basis,  is 
isolated  and  routed  to  node  188  by  the  probabilistic  branching 
from  node  182.  The  branch  percentage  value  of  8%  is  slightly 
more  than  the  percentage  theoretically  allotted  to  any  one  of 
the  other  12  lines.  This  branching  decision  is  once  again 
simply  a  starting  assumption  and  should  be  revised  in  the  face 
of  evidence  to  the  contrary.  As  previously  mentioned,  lotted 
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material  for  small  customers  (less  than  five  line  items)  is 
routed  to  the  parcel  post  line  without  sorting .  Therefore, 
each  item  will  be  processed  separately  and,  despite  the  fact 
that  a  majority  of  the  material  on  this  line  is  slated  for 
local  delivery,  each  item  will  be  assigned  a  parcel  post  pack 
plus  mark  time.  This  approach  was  adopted  to  model  NSC  San 
Diego's  current  procedure  of  mailing  local  delivery  material 
to  local  Fleet  customers.  Using  a  special  arrangement  with 
both  local  and  Naval  Station  postal  authorities,  this  procedure 
generally  leads  to  a  one  day  delivery  time,  which  represents 
an  improvement  over  the  delivery  time  normally  attained  through 
the  use  of  the  local  delivery  system.  If  this  practice  is 
discontinued,  a  regular  node  with  probabilistic  branching 
should  be  added  prior  to  node  188  to  provide  routing  to  either 
a  parcel  post  packing  value  assignment  or  a  local  delivery  time 
standard  with  a  lower  value.  Theoretically,  the  revision 
would  yield  a  parcel  post  line  network  identical  to  nodes  174 
through  176  of  the  IPG  I  processing  segment. 

Material  branching  from  node  182  to  the  other  12  lines  is 
immediately  assigned  an  attribute  6  value  of  0.009  hours  at 
node  183  to  represent  the  containerization  function.  Consoli¬ 
dation  will  occur  whether  the  material  is  destined  for  shipping 
or  local  delivery.  At  node  184  the  local  delivery  material  is 
segregated  and  routed  to  node  185  where  a  marking  time  is  added 
to  the  existing  attribute  6  value.  Therefore,  local  delivery 
material  is  not  assigned  any  additional  packing  time  beyond 
the  0.009  hours  established  at  node  183.  Since  the  mark  time 


standard  of  0.095  hours  applies  to  one  container,  the  addition 
to  each  line  item  at  node  185  is  factored  based  on  the  7.6 
line  items  per  rough  pack  assumption.  Implicit  in  the  treat¬ 
ment  of  local  delivery  material  is  the  assumption  that  con¬ 
solidation  is  occurring  in  light  pack  volume  containers.  If 
the  local  delivery  material  were  divided  into  light  and  heavy 
rough  pack  through  the  inclusion  of  an  additional  probabilistic 
branch  preceding  node  185,  the  mark  time  additive  for  heavy 
rough  pack  would  simply  be  reduced  to  half  the  light  pack 
value  since  twice  as  many  line  items  are  in  each  heavy  pack. 
Incidentally,  assigning  a  full  mark  time  to  local  delivery 
items  is  somewhat  erroneous;  the  marking  procedure  is  not  as 
complex  for  local  delivery  containers. 

The  bottom  branch  from  node  184  is  taken  by  material  des¬ 
tined  for  shipping.  The  30%  heavy  pack  branch  from  node  186 
again  has  no  statistical  basis;  it's  simply  a  starting  point. 
Parcel  post,  heavy,  and  light  pack  percentages  for  binnable 
material  were  not  readily  available.  The  attribute  6  additions 
at  nodes  186  and  201  represent  the  pack  plus  mark  value  des¬ 
cribed  below  the  nodes .  The  pack  time  addition  was  discussed 
earlier  in  this  section. 

The  actual  time  to  pack  and  mark  is  expended  on  the  branch 
between  nodes  189  and  190,  the  free  node  for  this  network  seg¬ 
ment.  The  conditional  branching  from  the  free  node  completes 
processing  on  parcel  post  items  plus  the  material  destined  for 
shipping;  the  parcel  post  attribute  6  value  will  equal  0.08 
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and  both  light  pack  (0.083)  and  heavy  pack  (0.109)  will  exceed 
the  node  190  upper  branch  lower  bound. 

Local  delivery  material,  having  an  attribute  6  value  of 
0.022,  will  be  routed  along  the  lower  branch  from  node  190, 
encounter  the  indicated  two  hour  delay  enroute  to  local  delivery 
staging,  and  will  be  probabilistically  assigned  by  node  191 
to  one  of  the  eight  indicated  delivery  zone  queues.  Local 
delivery  will  be  discussed  later  in  this  chapter.  It  suffices 
to  note  at  this  point  that  these  queues  will  be  emptied  in 
accordance  with  established  delivery  schedules.  Broadway  bulk 
material  and  National  City  local  delivery  material,  less  pro¬ 
visions  and  SERVMART,  are  also  shown  entering  node  191.  The 
direct  input  to  selected  zone  Q-nodes  consists  of  provisions 
and  National  City  SERVMART  material  from  Figure  9-3.  Neither 
of  these  material  categories  go  to  all  zones. 

The  issue  process,  and  particularly  the  packing  evolution, 
is  a  lucrative  area  for  analysis  through  the  use  of  alterna¬ 
tive  modeling  schemes.  All  13  lines  could  be  modeled  indi¬ 
vidually.  More  realistically,  the  large  customer  SP  and  LP 
lines  might  be  modeled  as  a  separate  entity  with  two  resources 
and  a  complete  heavy  pack  operation  in  recognition  of  customer 
volume.  The  parcel  post  line  is  also  a  superb  candidate  for 
distinct  resources.  As  noted  in  Chapter  8,  the  remaining  10 
packing  lines  are  basically  indistinguishable  due  to  the 
equalized  workload  principle.  However,  as  the  number  of 
independent  packing  lines,  and  hence  the  number  of  distinct 
resource  types,  increases,  provisions  must  be  made  for  idle 


resources  to  be  allocated  to  busy  lines;  the  packers  do  not 
remain  idle  if  there's  work  to  be  done  on  other  lines.  The 
example  shown  earlier  in  the  chapter  that  described  the  freeing 
of  resources  based  on  an  attribute  value  set  equal  to  the 
resource  type  could  be  used  to  eliminate  any  possibility  of 
idle  resources . 

It  should  be  apparent  that  the  branching  decisions  and 
time  assignments  made  throughout  the  issue,  packing,  and  mark¬ 
ing  networks  are  crude  at  best.  Knowledgeable  NSC  San  Diego 
personnel  should  review  and  modify  any  noticeably  inaccurate 
times  or  percentages  as  part  of  the  pre-simulation  validation 
process.  If  the  final  model  is  found  to  be  useful  for  the 
purposes  described  in  the  introduction.  It  is  imperative 
that  sufficient  data  be  collected  to  ultimately  prescribe  a 
model  that  approximates  reality  to  the  extent  that  it  can 
confidently  be  used  to  assess  the  relative  impact  of  various 
processing  alternatives. 

D.  NATIONAL  CITY  MATERIAL  PROCESSING 

The  National  City  operation  depicted  in  Figure  9-3  is 
composed  entirely  of  network  structures  that  have  been  described 
in  previous  discussions.  The  resources  allocated  at  nodes  203 
and  210  process  the  contents  of  Q-nodes  202,  208,  and  209  in 
the  same  manner  as  the  DPD  Keypunch  queues  on  Figure  7-7.  IPG 
Is  in  Q-node  202  are  processed  exclusively  by  the  type  14 
resources  at  allocate  node  203.  Similarly,  Q-node  209  provisions 
documents  are  issued  solely  by  the  type  15  resource  at  allocate 


node  210.  The  lotted  Q-node  208  National  City  issue  documents, 
which  include  QUICK  PIC  and  SERVMART  requests,  may  be  processed 
by  either  type  resource.  It  is  anticipated  that  the  lower 
volume  in  Q-node  202  will  lead  to  the  majority  of  the  lotted 
material  being  issued  by  type  14  resources.  Nevertheless, 
personnel  devoted  to  provisions  issues  will  issue  lotted 
material  from  Q-node  208  when  node  209  is  empty. 

Nodes  213  through  219  model  the  National  City  accumulation 
and  forwarding  of  warehouse  refusals  originated  at  free  nodes 
205  and  212  of  the  issue  processing  networks.  The  messenger 
arriving  at  node  216  is  the  National  City  driver  originally 
encountered  on  Figure  7-6.  The  operation  of  the  network  is 
identical  to  the  warehouse  refusal  processing  at  Broadway 
described  in  conjunction  with  Figure  9-1. 

Material  issues  take  the  0.99  branches  from  free  nodes  205 
and  212.  In  the  upper  issue  processing  network,  IPG  I  Bearers 
are  immediately  completed  at  node  206.  QUICK  PICs,  which 
theoretically  reside  at  the  head  of  Q-node  208  at  the  beginning 
of  each  work  day,  are  also  extracted  from  the  system  at  node 
206;  the  only  remaining  action  on  these  transactions  is  the 
delivery  to  the  designated  customer  pick-up  point.  The  FIFO 
queueing  philosophy  at  node  208  ensures  that  lotted  backlog  is 
worked  prior  to  beginning  the  issue  of  a  new  day's  documents. 
Therefore,  significant  backlogs  in  Q-node  208  may  prevent  the 
expeditious  processing  of  QUICK  PIC  issue  documents  and  present 
a  distorted  picture  of  actual  response  time  for  this  specific 
issue  category.  The  standard  Q-GERT  analysis  program  output 
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describing  Q-node  208  should  be  closely  reviewed  in  conjunction 
with  the  QUICK  PIC  output  statistics  collected  on  Figure  9-4. 
Bearing  in  mind  that  approximately  a  fifth  of  these  transac¬ 
tions  will  routinely  be  delayed  over  the  weekend,  an  unaccepta¬ 
bly  long  QUICK  PIC  response  time,  which  simply  does  not  occur, 
may  be  countered  through  one  of  the  following  model  revisions: 

(1)  Isolate  National  City  QUICK  PIC  documents  with  the  addition 
of  an  A3.EQ.3  branch  from  node  138  on  Figure '8-2  and  route 
them  to  Q-node  202  on  Figure  9-3  where  they  will  be  processed 
directly  after  IPG  Is;  or  (2)  perform  the  same  isolation  as 
above  but  route  them  to  Provisions  Q-node  209 ,  which  would 
have  its  ranking  designator  changed  to  S/3.  A  similar  analysis 
should  be  conducted  on  Q-nodes  143  (bulk)  and  148  (bin)  on 
Figure  9-1.  A  remedial  action  similar  to  alternative  (1)  and 
featuring  conditional  branching  of  QUICK  PICs  directly  from 
nodes  136  and  137  on  Figure  8-2  to  IPG  I  queues  147  and  142, 
respectively,  on  Figure  9-1  may  be  instituted  if  necessary. 
Although  the  routing  of  QUICK  PICs  to  the  IPG  I  queues  may  have 
been  the  most  accurate  modeling  approach  from  the  outset,  the 
technique  actually  used  was  deliberately  chosen  to  force  an 
initial  analysis  of  standard  Q-GERT  output  for  a  specific 
material  category.  It  was  considered  advantageous  for  the 
understanding  of  both  Q-GERT  symbology  and  standard  program 
output  to  provide  a  specific  analytical  starting  point  for 
which  the  remedial  modeling  change,  if  needed,  would  be 
relatively  minor. 
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Returning  to  Figure  9-3  at  node  206,  it  should  be  noted 
that  SERVMART  transactions  are  routed  to  node  222  with  a  1.5 
hour  delay  for  distribution  to  specific  delivery  zone  queues. 
This  procedure  differs  from  the  treatment  given  Broadway 
SERVMART  material,  which  was  considered  complete  with  routing 
to  SERVMART  Central  Receiving.  There  is  no  provisions  (A3.EQ.7) 
branching  from  node  206  because  the  upper  network  does  not 
process  that  material  category. 

The  bottom  branch  from  node  206  routes  the  remaining  mater¬ 
ial  to  the  local  delivery  or  shipping/packing  determination  at 
n  de  207.  Local  delivery  material  is  branched  to  node  233 
where  IPG  Is  are  completed  and  the  remaining  material  is  de¬ 
layed  1.5  hours  enroute  to  the  full  range  local  delivery  zone 
branching  at  node  191  on  Figure  9-2.  The  conditional  branch¬ 
ing  encountered  at  node  232  for  items  to  be  packed  segregates 
the  IPG  I  issues,  delays  them  only  0.5  hours  vice  1.0  hour 
for  lower  priorities,  and  designates  the  routing  to  Q-node 
223,  the  IPG  I  packing  queue.  The  remaining  material  to  be 
packed  is  routed  along  the  lower  branch  from  node  232  to  pack¬ 
ing  Q-node  224.  Note  that  node  207  also  makes  the  packing 
decision  on  material  issued  in  the  lower  network  segment;  the 
lower  branch  from  node  220  accomplishes  the  desired  routing 
up  to  node  207. 

The  issue  processing  network  using  type  15  resources  func¬ 
tions  in  a  similar  manner.  However,  provisions  issues,  which 
are  made  only  by  this  resource,  must  be  isolated  and  routed  to 
the  appropriate  delivery  zones.  The  segregation  occurs  at  node 


220  and  the  probabilistic  branching  to  selected  delivery  zones 
is  performed  at  node  221.  The  illustrated  modeling  scheme 
assumes  all  provisions  requests  are  from  local  customers  and 
the  distribution  of  material  issued  is  basically  equal  across 
all  delivery  zones.  If  these  assumptions  are  erroneous,  the 
appropriate  network  branching  must  be  incorporated  into  the 
model  and  the  corresponding  Q-GERT  cards  changed  accordingly. 

Once  material  has  been  routed  to  Q-nodes  223  and  224,  the 
packing  queues.  National  City  issues  are  packed  and  marked 
using  network  symbology  identical  to  the  Figure  9-1  Broadway 
bulk  packing  model.  The  mark  standard  of  0.095  hours  and  the 
parcel  post  0.1  hour  value  are  the  same  at  both  locations,  but 
the  light  and  heavy  packing  times  at  National  City  are  higher. 
Note  that  there  are  three  times  more  pack/mark  resources  at 
National  City  (9  type  16)  than  at  Broadway  (3  type  11) .  In¬ 
asmuch  as  there  is  a  significantly  larger  percentage  of  light 
and  heavy  pack  accomplished  at  Broadway,  initial  simulations 
may  lead  to  both  a  large  backlog  in  the  Broadway  packing  queue, 
Q-node  163  on -Figure  9-1,  and  a  significant  percentage  of  time 
idle  for  type  16  resources  at  National  City.  The  higher  per¬ 
centages  of  light  and  heavy  pack  at  Broadway  more  than  compen¬ 
sate  for  the  higher  pack  times  at  National  City.  Furthermore, 
the  volume  entering  Broadway  will  theoretically  be  higher  due 
to  the  exclusion  of  provisions  from  National  City  packing. 

The  Broadway  pack  type  percentages  were  supplied  by  the  packing 
supervisor.  The  National  City  percentages  were  estimated 
based  on  the  following  data  regarding  pack  type  manpower 
assignments: 
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.  4  individuals  are  assigned  to  the  light  pack  function 

which  requires  0.465  hours  per  pack 
.  2  individuals  are  assigned  to  the  heavy  pack  function 

which  requires  1.43  hours  per  pack 
.  2  individuals  are  assigned  to  the  parcel  post  function 

which  requires  0.1  hours  per  pack 
Assuming  that  the  individuals  assigned  accomplish  the  required 
packing  with  negligible  idleness  and  with  minimal  shifting  of 
resources  across  functions,  it  was  inferred  that  there  is  14 
times  more  parcel  post  business  than  heavy  pack;  the  same 
number  of  people  are  kept  busy  performing  a  function  that  takes 
approximately  1/14  of  the  time  needed  for  a  heavy  pack.  Simi¬ 
larly,  the  ratio  between  parcel  post  and  light  pack  personnel 
assigned  and  pack  times  implies  that  there  is  approximately  2.3 
times  more  parcel  post  volume  than  light  pack.  Therefore,  a 
ratio  of  1:2.3:14  applies  for  parcel  post,  light,  and  heavy 
pack.  The  indicated  percentages  on  the  branches  entering  nodes 
227  through  229  approximate  that  ratio,  but  are  suspect  in 
view  of  the  corresponding  Broadway  bulk  percentages.  There¬ 
fore,  standard  Q-GERT  output  for  Q-nodes  163  and  224  and  the 
utilization  of  type  11  and  16  resources  should  be  closely  scru¬ 
tinized.  The  resource  levels  and  pack  type  percentages  should 
also  be  reviewed  on-site  with  appropriate  packing  supervisory 
personnel.  If  National  City  packing  processes  a  significant 
input  not  included  in  this  model,  then  the  indicated  resource 
capacity  and/or  pack  percentages  are  invalid.  Furthermore, 
if  parcel  post  packers  spend  a  significant  part  of  their  time 


assisting  in  the  light  or  heavy  pack  evolution,  an  adjustment 
corresponding  to  their  degree  of  involvement  must  be  made. 
Finally,  the  packing  percentages  are  also  based  on  the  assump¬ 
tion  that  only  one  person  is  required  to  pack  one  line  item, 
regardless  of  the  pack  type  used.  A  determination  that  two 
people  are  used  on  each  heavy  and/or  light  pack  would  obviously 
alter  these  percentages . 

E.  LOCAL  DELIVERY 

The  Q-GERT  symbology  modeling  the  local  delivery  system 
consists  of  the  delivery  zone  queues  on  Figures  9-2  and  the 
allocate  node  network,  nodes  232  through  236,  on  Figure  9-4. 

The  zone  percentages  emanating  from  node  191  on  Figure  9-2 
were  supplied  by  Production  Planning  representatives.  The 
zone  percentages  for  National  City  provisions  and  SERVMART 
material  given  on  Figure  9-3  and  shown  entering  selected  Figure 
9-2  delivery  zones  from  nodes  221  and  222  may  be  categorized 
as  strictly  arbitrary.  Since  only  5%  of  all  SERVMART  replenish¬ 
ments  are  issued  from  National  City,  revision  of  the  branching 
proportions  from  node  222  should  have  little  impact  on  the 
operation  of  the  model.  The  provisions  percentages  should  be 
reviewed,  however.  The  equal  branching  assumption  should  be 
changed  in  the  event  that  a  higher  percentage  is  routinely 
delivered  to  particular  zones;  e.g.,  if  two  large  customers 
such  as  MCRD  (Marine  Corp  Recruiting  Depot)  and  NTC  (Naval 
Training  Center)  occupy  the  same  zone,  the  percentage  assigned 
to  that  zone  on  Figure  9-3  should  be  adjusted  accordingly. 
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The  Figure  9-2  zone  queues  effectively  model  the  staging 
of  material  for  local  customers  by  delivery  zone.  At  the  time 
of  this  writing,  material  was  being  staged  strictly  by  UIC  at 
the  Broadway  complex.  Therefore,  a  significant  manpower 
investment  dedicated  to  locating  all  the  material  for  a  par¬ 
ticular  zone  was  required  to  determine  the  transportation  re¬ 
sources  needed  to  effect  delivery  the  following  day.  The 
rationale  for  this  seemingly  inefficient  staging  method  is 
unknown.  The  cost  associated  with  converting  to  a  UIC  within 
delivery  zone  system  apparently  has  either  never  been  esti¬ 
mated  or  found  to  be  prohibitive.  If  the  former  is  the  case, 
it  would  appear  prudent  to  assess  the  costs  and  benefits 
associated  with  implementing  a  staging  technique  that  would 
both  simplify  the  determination  of  the  transportation  resource 
requirement  and  reduce  the  possibility  of  inadvertently  over¬ 
looking  small  local  customers  spread  throughout  the  staging 
area . 

There  is  a  local  delivery  staging  area  at  both  Broadway 
and  National  City.  However,  since  material  from  each  location 
is  delivered  on  the  same  schedule  to  appropriate  zones,  the 
modeled  approach  consolidates  them  into  one  delivery  system. 
The  following  nine  zones,  with  their  respective  locations  and 
delivery  schedules  given,  comprise  the  NSC  San  Diego  local 
delivery  operation: 
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ZONE 

NUMBER 

LOCATION 

DELIVERY 

SCHEDULE 

1 

PIER  1 

Monday  and  Thursday 

2 

PIER  2 

Monday  and  Tuesday 

3 

PIER  3 

Monday  and  Tuesday 

4 

LONG  BEACH 

Daily 

5 

NAVAL  STATION 

Monday  and  Wednesday 

6 

POINT  LOMA 

Tuesday  and  Thursday 

7 

NAS  MIRAMAR 

Tuesday  and  Friday 

8 

NAS  NORTH  ISLAND 

Monday  and  Thursday 

9 

NSC  SAN  DIEGO 
(INTERNAL)  AND  TENANT 

Daily 

ACTIVITIES 

Although  there  are  nine  2ones  listed  above,  only  eight  zone 
queues  appear  on  Figure  9-2.  Piers  2  and  3,  which  share  the 
same  delivery  schedule  and  the  same  transportation  method 
(usually  straddle  truck) ,  were  combined  into  a  single  delivery 
zone.  Pier  1  and  NAS  North  Island,  zones  1  and  8,  also  have 
a  common  delivery  schedule,  but  require  different  transporta¬ 
tion  resources  to  physically  move  the  material.  Therefore, 
these  zones  were  modeled  as  distinct  despite  their  common 
schedule . 

A  change  to  the  above  zone  definitions  may  have  occurred 
before  the  distribution  of  this  report.  Material  previously 
designated  for  zones  1  through  3  above  will  eventually  be 
designated  as  Naval  Station,  zone  5,  issues.  Once  implemented, 
this  procedural  change  will  restrict  the  zone  designators 
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appearing  on  DD  1348-1  issue  documents  to  4  through  9.  Piers 
1,  2,  and  3  are  located  at  the  Naval  Station,  a  factor  that 
tends  to  support  a  common  zone  designation.  However,  the 
delivery  schedule  for  the  four  affected  areas  will  purportedly 
remain  the  same.  Therefore,  the  existing  modeling  approach 
will  remain  valid  despite  the  revised  2one  designations.  Of 
course,  any  change  in  delivery  schedules  would  necessitate 
model  revisions. 

Numerous  techniques  could  have  been  used  to  account  for 
the  Transportation  Hold  Time  in  local  delivery.  In  fact,  if 
each  requisition's  time  in  the  system  were  the  only  factor  of 
interest,  there  would  be  no  need  for  either  the  Figure  9-2 
Q-node  network  or  the  Figure  9-4  resources  to  process  the  Q- 
node  contents.  Following  the  zone  determination  at  node  191, 
221,  or  222,  each  transaction  could  be  assessed  a  delay  deter¬ 
mined  by  a  distinct  user  function  for  each  zone.  The  delay 
assigned  would  be  computed  as  the  difference  between  the  next 
scheduled  delivery  day  for  that  zone  and  the  current  day, 
which  could  be  computed  from  simulation  time  through  the  use 
of  modulo  arithmetic.  Having  experienced  the  appropriate 
delay,  each  transaction  would  be  routed  to  the  statistics 
collection  network.  This  technique  was  considered  inadequate 
for  the  following  reasons:  (1)  It  does  not  provide  illustra¬ 
tive  Q-GERT  graphics  of  local  delivery,  an  exceptionally  criti¬ 
cal  requisition  processing  functional  area;  (2)  it  does  not 
represent  a  modeling  approach  that  can  readily  be  modified  to 
incorporate  either  additional  complexity  or  ensuing  processing 
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Figure  9-4.  Local  Delivery  and  Issue  Statistics 


functions;  and  (3)  the  FORTRAN  background  of  the  model's 
potential  users  may  not  be  broad  enough  to  include  an  exposure 
to  concepts  such  as  the  modulo  function.  A  stated  objective 
of  the  model  is  to  initially  minimize  both  the  quantity  and 
complexity  of  FORTRAN  program  inserts. 

The  selected  modeling  scheme  has  none  of  the  aforementioned 
objectionable  features.  It  visually  portrays  each  distinguish¬ 
able  zone's  staging  area  as  a  Figure  9-2  Q-node.  The  dashed 
line  leaving  each  Q-node  terminates  at  a  connector  containing 
a  list  of  the  Figure  9-4  allocate  nodes  that  process  trans¬ 
actions  residing  in  that  queue.  There  is  one  allocate  node 
for  each  weekday.  Therefore,  the  ALL  designator  on  the  connec¬ 
tors  for  Q-nodes  194  (Long  Beach)  and  170  (NSC  San  Diego)  indi¬ 
cates  that  resources  are  allocated  for  these  queues  each  day; 
i.e.,  there  are  daily  deliveries  to  Long  Beach  and  NSC  San 
Diego.  Of  course,  the  Figure  9-2  method  of  indicating  routing 
to  multiple  nodes  is  not  a  standard  Q-GERT  graphical  technique. 
Five  dashed  lines  should  have  been  originated  at  Q-nodes  194 
and  170  and  terminated  at  connectors  labeled  232  through  236. 
Space  constraints  on  Figure  9-2  prevented  the  use  of  the  con¬ 
ventional  graphical  method.  The  appropriate  standard  routing 
is  depicted  on  Figure  9-4. 

The  five  dissimilar  resource  types  at  allocate  nodes  232 
through  236  are  controlled  from  the  timing  network.  The  indi¬ 
cated  capacity  of  1  for  each  resource  is  immediately  altered 
to  zero.  The  positive  integer  initial  capacity  is  necessary 
to  avoid  a  fatal  input  error,  which  will  inhibit  the  simulation 
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run.  The  immediate  altering  to  zero  prevents  the  processing 
of  queued  transactions  until  1000  of  the  indicated  weekday 
when  one  resource  will  be  provided  to  empty  all  queues  ser¬ 
viced  by  the  available  resource  type.  The  logic  associated 
with  the  local  delivery  network  is  basically  identical  to  the 
ADP  resource  allocation  symbology  on  Figure  3-2.  The  only 
notable  difference  is  the  frequency  of  resource  availability; 
each  ADP  resource  is  provided  daily  for  a  specified  time  inter¬ 
val  while  delivery  resources  are  made  available  once  each  week 
for  a  one  hour  period  beginning  at  1000.  The  0.00005  hour  local 
delivery  processing  rate,  which  is  even  faster  than  the  ADP 
rate,  was  chosen  to  virtually  guarantee  that  all  the  material 
in  the  given  day's  zones  (Q-nodes)  will  be  removed  within  the 
allotted  hour.  In  addition,  transactions  arriving  during  the 
hour  that  resources  are  available  will  be  processed  if  time 
permits.  It  appears  reasonable  to  assume  that  material  arriving 
prior  to  the  completion  of  loading  for  delivery  to  a  particular 
zone  would  be  included  in  that  day's  delivery  if  adequate  space 
is  available. 

The  zone  4  Long  Beach  queue,  which  normally  contains  a 
large  volume  of  higher  priority  material,  will  be  designated 
the  preferred  queue  at  each  allocate  node.  Q-node  170  material 
for  NSC  San  Diego  and  its  tenant  activities,  which  is  also 
delivered  daily,  will  be  coded  as  the  least  preferred  queue. 
Special  transportation  resources  are  not  generally  provided 
for  this  material.  Broadway  material  for  this  zone  is  already 
on-site.  National  City  issues  are  normally  included  with  the 
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shipment  of  Broadway  material  receipts  that  were  inappro¬ 
priately  delivered  to  National  City.  Using  the  resource 
freeing  techniques  described  in  Section  IX. D,  nodes  237  through 
241  assign  the  resource  type  as  attribute  7  of  each  transaction 
routed  through  them.  The  resources  may  then  be  freed  at  the 
single  network  free  node,  node  243,  and  returned  to  the  appro¬ 
priate  allocate  node.  Issues  of  local  delivery  material  are 
considered  complete  after  being  removed  from  their  respective 
Q-nodes  and  assessed  the  negligible  0.00005  hour  delay.  There¬ 
fore,  the  indicated  conditional  branching  is  taken  from  the 
local  delivery  network  free  node  to  the  appropriate  statistics 
collection  network  segments  described  in  the  next  section. 

The  local  delivery  model  selected  assumes  the  availability 
of  sufficient  transportation  resources  to  deliver  all  staged 
material.  However,  it  could  be  easily  modified  to  include  an 
assessment  of  transportation  requirements  at  the  beginning  of 
each  work  day  by  evaluating  Q-node  contents  from  the  timing 
network.  The  same  FORTRAN  user  function  sown  in  Appendix  D 
and  used  in  the  messenger  routing  system  would  apply.  Based 
upon  the  queue  contents,  a  specific  number  of  the  appropriate 
resource  type  could  then  be  provided  and  a  more  realistic  pro¬ 
cessing  time  assigned  between  nodes  242  and  243.  In  fact,  the 
network  could  be  retained  in  its  present  form  with  the  exception 
of  the  free  node  243  branching  and  used  to  provide  the  daily 
input  to  a  transportation  model.  A  given  day's  material  for 
local  delivery  could  be  routed  to  free  node  243  and  deter¬ 
ministically  branched  to  a  Q-node  that  would  serve  as  the  input 
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queue  for  the  transportation  network.  Decisions  on  required 
transportation  resources,  both  personnel  and  vehicles,  could 
then  be  made  based  on  the  contents  of  the  added  queue.  Of 
course,  the  removal  of  material  from  local  delivery  staging 
should  be  accomplished  earlier  than  1000,  perhaps  the  day 
before,  and  some  provision  to  assess  the  impact  of  consolida¬ 
tion  would  have  to  be  made;  the  zone  queues  contain  line  items 
rather  than  the  actual  consolidated  material. 

F.  STATISTICS  COLLECTION 

The  remainder  of  Figure  9-4  is  devoted  to  the  collection 
of  issue  statistics  on  various  material  categories.  Each  node 
with  an  I  designation  will  automatically  provide  statistical 
output  delineating  time  in  system  variables  such  as  the  average 
across  all  simulation  runs,  the  standard  deviation  of  this 
average,  and  the  minimum  and  maximum  times  encountered.  A 
histogram  may  also  be  provided  by  defining  the  first  cell  upper 
limit  in  Field  7  of  the  STAtistics  node  Q-GERT  card.  The 
card  format  permits  labeling  each  STA  node  for  ease  of  output 
identification.  The  label  assigned  to  each  node  on  Figure  9-4 
is  shown  in  the  vicinity  of  the  node. 

Statistics  nodes  may  be  inserted  throughout  the  network  to 
collect  data  of  interest.  Since  the  STA  node  input  card  in¬ 
cludes  provisions  for  defining  the  histogram  cell  width,  the 
number  of  transactions  having  a  current  time  in  system  greater 
than  some  predetermined  standard  can  be  displayed  in  the  last 
histogram  cell.  Furthermore,  statistics  on  transaction  time 
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in  selected  functional  areas  may  readily  be  obtained  through 
the  use  of  mark  nodes  and  STA  nodes.  The  arrival  time  of  the 
transaction  assigned  on  Figure  6-5  or  6-6  need  not  accompany 
the  requisition  throughout  the  model.  Including  the  M  desig¬ 
nator  at  any  regular  network  node  will  result  in  a  change  of 
the  mark  time  attribute  to  current  simulation  time.  Therefore, 
if  the  collection  of  interval  statistics  on  all  transactions 
leaving  Customer  Services  is  followed  by  the  assignment  of  a 
new  mark  time,  the  next  interval  data  collected  will  measure 
the  time  following  transaction  departure  from  Customer  Services. 
Of  course,  this  technique  would  invalidate  the  use  of  the 
Figure  9-4  statistics  as  a  measure  of  total  processing  time; 
the  statistics  collected  would  only  measure  the  time  between 
the  last  marking  and  issue  completion. 

A  second  method  of  conveniently  determining  average  trans¬ 
action  time  in  a  particular  network  segment  involves  the  use 
of  the  multiple  routing  feature  of  deterministic  branching. 
Assume  that  all  transactions  leaving  a  specified  area  are 
routed  to  a  regular  node  with  deterministic  branching.  Since 
a  duplicate  of  each  arriving  transaction  will  be  forwarded  along 
every  branch  leaving  the  node,  the  requisitions  can  be  routed 
on  separate  branches  to  both  a  statistics  node  and  the  next 
processing  station  without  any  mark  time  change.  Each  set  of 
statistics  collected  in  thismanner  represents  transaction  time 
in  the  system  at  that  point.  Therefore,  the  time  in  a  particu¬ 
lar  processing  area  may  be  computed,  or  at  least  inferred, 
from  two  successive  sets  of  output  statistics. 
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As  previously  mentioned,  only  the  most  rudimentary  sta¬ 
tistics  collection  features  are  programmed  into  the  initial 
version  of  the  model.  The  collection  of  data  on  the  time 
between  transactions  was  accomplished  w^th  referrals  on 
Figure  7-6  and  interval  statistics  are  collected  with  the 
Figure  9-4  network  logic.  A  practically  unlimited  degree  of 
data  collection  sophistication  may  be  included  in  subsequent 
versions  through  the  use  of  FORTRAN  inserts  in  conjunction 
with  the  guidance  on  user  collected  statistics  provided  in 
Chapter  9  of  reference  (a) . 

A  node-by-node  description  of  the  Figure  9-4  issue  statis¬ 
tics  network  will  not  be  given.  No  additional  Q-GERT  concepts 
are  introduced,  the  symbology  used  is  relatively  simple,  and 
the  material  category  for  which  the  statistics  are  being 
collected  is  shown  at  the  node. 

G.  POTENTIAL  PROCEDURAL  CHANGES 

An  evaluation  of  existing  operational  methods  is  constantly 
in  process  at  NSC  San  Diego.  In  addition  to  the  analysis  of 
existing  DPD  procedures  covered  in  Chapters  5  and  8,  two  pro¬ 
cedural  changes  presently  being  contemplated  in  the  material 
issue  process  are  worthy  of  note  at  this  juncture. 

First,  a  change  to  the  existing  method  of  issuing  and 
packing  Broadway  binnables  is  under  consideration.  The  current 
procedure  calls  for  all  bin  material  to  be  routed  through  packing. 
The  revised  procedure  would  eliminate  approximately  40%  of  the 
packing  local  delivery  workload  by  accomplishing  the 


containerization  of  this  material  during  the  pre-packing  UIC 
sort  discussed  in  Section  IX. C.  The  consequences  of  this 
particular  type  of  revision  could  readily  be  evaluated  using 
this  model.  A  regular  node  with  probabilistic  branching  could 
be  inserted  in  the  bottom  branch  leaving  node  160  on  Figure 
9-1.  This  node  would  route  60%  of  all  arriving  transactions 
to  node  171  on  Figure  9-2  and  redirect  40%  to  an  alternate 
packing  queue  and  network  similar  to  nodes  179,  180,  183,  185, 
and  189  on  Figure  9-2.  A  statistics  node  should  also  be  added 
after  node  189.  Supplying  one  resource  at  the  new  packing  sta¬ 
tion  and  simulating  the  revised  model  for  a  specified  time 
period  would  permit  an  assessment  of  both  production  rate  and 
backog  at  the  additional  station  and  the  impact  of  the  decreased 
workload  on  the  current  packing  operation.  Therefore,  an 
estimate  of  the  personnel  reassignments  needed,  if  any,  to 
implement  the  procedure  could  be  deduced  from  standard  Q-GERT 
output  for  the  relevant  Q-nodes  and  statistics  nodes.  If  the 
additional  workload  were  to  be  assimilated  by  the  issue  re¬ 
source,  type  10  on  Figure  9-1,  the  impact  could  be  observed 
by  slightly  increasing  the  issue  time  on  40%  of  all  binnable 
issues . 

The  second  proposed  change  involves  the  application  of  the 
complete  scope  of  Production  Planning  capabilities  to  the  issu¬ 
ing  of  IPG  III  binnable  material.  The  procedure,  which  was 
briefly  discussed  at  the  end  of  Chapter  8,  involves  a  time 
phased  release  of  IPG  III  material  for  local  customers  based 
upon  the  scheduled  delivery  date.  The  program  objective  was 
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to  have  the  material  arrive  at  the  staging  area  during  the 


afternoon  preceding  delivery.  The  new  initiative  goes  one 
step  further  and  includes  the  addition  of  a  conveyor  system 
upon  which  the  material  will  be  transported  directly  to  waiting 
delivery  vehicles.  This  procedure  would  obviously  be  more 
difficult  to  model.  If  the  procedure  is  in  effect  when  the 
second  phase  of  this  project  begins,  the  necessary  model  revi¬ 
sions  should  definitely  be  made.  A  suggested  starting  point 
is  the  Figure  8-2  lotting  logic;  a  zone  determination  could 
be  made  on  local  delivery  material  with  probabilistic  branch¬ 
ing  similar  to  node  191  on  Figure  9-2.  A  variable  delay  could 
then  be  assessed  for  each  transaction  based  on  current  simula¬ 
tion  time  and  the  next  scheduled  delivery.  Of  course,  addi¬ 
tional  network  logic  would  also  have  to  be  changed.  The  zone 
staging  Q-nodes,  for  example,  would  simply  not  receive  any 
IPG  III  material. 
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X.  NETWORK  TIMING 


A.  TIMING  OVERVIEW 

The  network  timing  logic  is  used  to  initiate  messenger 
runs,  apply  and  remove  ADP,  local  delivery,  and  personnel 
resources,  and  change  the  autodin  and  POE  arrival  patterns  on 
a  daily  basis.  Numerous  modeling  approaches  could  be  used 
to  provide  the  exact  timing  scheme  developed  in  this  chapter. 
The  most  efficient  method  would  place  a  heavy  reliance  on 
FORTRAN  program  inserts.  The  seclected  method  was  chosen  for 
both  its  simplicity  and  the  ease  with  which  it  may  be  modi¬ 
fied  and/or  expanded  to  provide  weekend  or  midnight  shift 
resources . 

There  are  two  basic  approaches  that  may  be  used  to  model 
the  standard  five  day  work  week.  If  the  functions  occurring 
each  day  are  identical,  the  most  convenient  technique  involves 
the  modeling  of  one  day's  events  and  a  decision  network  that 
provides  five  repetitions  of  the  same  sequence  of  events  before 
initiating  a  weekend  delay.  If  the  daily  events  differ  signi¬ 
ficantly,  it  becomes  less  confusing  if  a  representation  of  the 
entire  week  is  modeled  and  relevant  functions  are  initiated 
from  each  specific  day.  Of  course,  the  former  approach  uses 
significantly  less  nodes  and  represents  the  ideal  technique 
for  any  approach  that  is  heavily  dependent  on  FORTRAN  inserts. 
For  example,  as  each  repetition  of  the  standard  day's  network 
is  initiated,  a  user  function  could  be  called  to  determine 
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which  day  of  the  week  was  commencing  and  what  events  must  be 
scheduled.  Mindful  of  the  objective  to  minimize  program  in¬ 
serts  in  the  initial  model,  the  timing  network  contains  no 
FORTRAN  logic.  A  disjoint  network  for  the  entire  week  is 
provided.  However,  in  an  attempt  to  illustrate  both  of  the 
aforementioned  techniques,  the  initiation  of  the  entire  week's 
schedule  of  selected  events  occurs  on  Monday  rather  than  on 
a  daily  basis. 

B.  WEEKLY  MASTER  AND  RESOURCE  INITIALIZATION 

The  upper  portion  of  Figure  10-1  contains  a  source  node, 
node  265,  and  a  closed  loop  of  nodes  and  delays  that  total 
168  hours  or  one  week.  The  model  itself,  and  each  successive 
week,  starts  on  Monday  at  0430,  the  time  indicated  on  both 
sides  of  node  266.  The  time  was  indicated  twice  as  a  reminder 
that  transaction  time  through  a  regular  node  is  zerop  i.e., 
there  is  no  delay  at  a  regular  node  that  requires  only  one 
transaction  to  release  it.  The  0430  start  time  was  chosen  to 
correspond  to  the  changing  of  the  autodin  daily  demand  dis¬ 
tribution.  Since  autodin  referral  input  usually  originates 
at  east  coast  ICPs,  it  appeared  reasonable  to  program  the 
demand  pattern  change  at  the  beginning  of  the  ICP  working  day. 

Two  regular  nodes  representing  0430  and  1530  are  encoun¬ 
tered  for  each  day  of  the  week.  The  routing  from  nodes  266 
and  267  occurs  on  Monday  and  the  61  hour  delay  initiated  on 
Friday  at  1530  from  node  275  is  the  weekend  delay.  Obviously, 
a  Saturday  shift  could  easily  be  added  by  inserting  regular 
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Figure  10-1.  Weekly  Master,  Initialization,  and  DPD  Keypunch  Control 


nodes  after  node  275  to  represent  specific  times  and  decreasing 
the  indicated  61  hour  delay  accordingly.  The  1530  time  desig¬ 
nation  was  chosen  to  correspond  to  the  termination  of  the 
daily  eight  hour  POE  input.  Since  POE*  input  is  terminated 
by  a  nodal  modification  procedure  triggered  by  the  completion 
of  specific  activities,  the  11  hour  delays  preceding  each  1530 
node  are  assigned  activity  numbers  that  are  referenced  on 
Figure  10-4. 

Each  0430  node  routes  two  transactions  to  node  287  on 
Figure  10-2,  the  personnel  resource  control  network.  The 
transaction  with  the  three  hour  delay  arrives  at  node  287  at 
0730  and  sets  all  personnel  resource  types  to  the  capacity 
indicated  above  the  allocate  nodes  displayed  in  earlier  chap¬ 
ters.  The  other  transaction  sent  to  node  287  is  delayed  7.5 
hours  and  restores  the  resources  at  1200  after  their  removal 
for  a  0.5  hour  lunch  at  1130.  The  removal  of  all  resources, 
which  is  also  initiated  at  each  0430  node,  is  accomplished 
by  the  routing  to  node  303  on  Figure  10-2.  The  seven  hour 
delay  programs  the  transaction's  arrival  at  1130. 

The  routing  of  two  transactions  to  node  287  and  one  to 
node  303  is  common  to  each  0430  node  in  the  week.  However, 
Monday's  node  has  three  additional  branches  that  initiate  net¬ 
work  segments  that  provide  a  full  week's  scheduling.  The 
transaction  arriving  at  node  347  on  Figure  10-3  after  a  2.5 
hour  delay  initiates  the  day  shift  activities  of  the  Broadway 
Complex  messenger  and  the  National  City  driver.  The  transac¬ 
tion  routed  to  node  342  on  Figure  10-3  initiates  local  delivery 
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resource  control  for  the  week.  Finally,  the  routing  to 
Figure  10-4,  node  358,  leads  to  the  control  of  a  full  week's 
batch  processing,  QUICK  PIC  keypunching,  and  ADP  resource 
allocation. 

Node  270,  the  Wednesday  0430  node,  has  one  unique  branch 
to  node  285  to  provide  specific  resource  control  for  DPD  key¬ 
punch  personnel,  resource  types  3  and  4  on  Figure  7-7.  This 
special  network  segment,  which  is  shown  on  the  bottom,  middle 
portion  of  Figure  10-1,  serves  to  eliminate  these  resources  for 
a  1.5  day  period  every  two  weeks  to  model  payday  impact.  A 
transaction  is  sent  from  node  270  to  node  285  at  0430  each 
Wednesday.  However,  node  285  will  not  be  released  until  two 
transactions  have  arrived.  Therefore,  every  other  Wednesday 
node  285  is  released  and  activities  16  and  17,  representing 
delays  of  7.25  and  36.25  hours,  respectively,  are  initiated. 
Activity  16  will  be  completed  at  1145  on  Wednesday,  a  time 
during  which  all  resources  have  been  removed  for  lunch.  The 
completion  of  this  activity  prompts  the  modification  of  nodes 
288,  304,  and  320  on  Figure  10-2  and  inhibits  any  resource 
changes  until  activity  17,  the  36.25  hour  delay  completes  and 
reinserts  those  nodes  in  the  network.  The  completion  of 
activity  17  occurs  at  1615  on  Thursday  or  15  minutes  after 
the  normal  removal  of  DPD  keypunch  resources  on  each  working 
day.  Therefore,  DPD  keypunch  resources,  having  been  removed 
for  Wednesday  afternoon  and  Thursday,  will  be  provided  once 
again  at  0730  on  Friday. 
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Each  1530  node  in  the  weekly  master  network  has  the  same 
two  branches.  First,  a  transaction  is  delayed  0.5  hours  and 
sent  to  node  319  on  Figure  10-2  to  initiate  the  1600  shift/ 
resource  change.  Finally,  a  transaction  is  sent  to  node  353 
on  Figure  10-3  to  trigger  the  network  that  provides  second 
shift  messenger  service  for  both  the  Broadway  Complex  and 
National  City. 

To  conclude  the  discussion  of  Figure  10-1,  the  branching 
from  node  265,  a  source  node,  to  nodes  303  and  276  must  be 
considered.  The  routing  without  delay  to  node  303  on  Figure 
10-2,  which  is  normally  accessed  to  remove  all  personnel  re¬ 
sources  for  the  lunch  break,  is  a  one  time  initialization  of 
all  personnel  resources  to  zero.  If  this  step  were  omitted, 
the  transaction  arriving  at  node  287  at  0730  from  node  266 
would  result  in  twice  the  defined  capacity  of  each  personnel 
resource  being  available.  The  RES  card  for  each  resource 
contained  a  capacity  field  and,  in  the  absence  of  an  altering 
action,  that  capacity  is  assumed  to  exist  when  the  simulation 
commences.  Therefore,  the  altering  of  resources  up  to  capacity 
that  is  initiated  at  node  287  would  actually  double  all  re¬ 
sources  that  were  not  initially  zeroed. 

The  transaction  routed  from  node  265  to  node  276  also  pro¬ 
vides  an  intialization  function.  It  was  mentioned  in  Chapters 
7  and  9  that  the  ideal  initial  capacity  for  ADP  and  local 
delivery  resources  would  be  zero,  an  assignment  that  was  pro¬ 
hibited  due  to  the  requirement  for  a  positive  integer  capacity. 
Therefore,  these  particular  resources  were  defined  with  a  RES 
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card  capacity  of  one,  which  would  immediately  be  reduced  to 
the  desired  zero  value  and  made  available  when  required.  The 
network  consisting  of  nodes  276  through  284  simply  accomplishes 
the  desired  reduction  to  zero  for  both  ADP  resources  at  nodes 
277  through  279  and  local  delivery  daily  resources  at  nodes 
280  through  284. 

The  final  branch  emanating  from  the  source  node  triggers 
the  disjoint  timing  network  beginning  with  node  369,  which 
is  above  the  Figure  10-1  DPD  keypunch  control  segment.  Once 
initiated,  this  segment  runs  continuously.  The  completion  of 
each  activity  signifies  the  end  of  a  shift.  Activity  18, 
which  completes  at  1600,  represents  the  end  of  the  first  shift. 
Activities  19  and  20  are  completed  at  2400  and  0730,  respec¬ 
tively,  and  model  the  end  of  second  and  third  shifts.  The 
completion  of  activities  18  and  19  controls  the  Figure  7-5 
nodal  modification  between  nodes  48  and  51.  Since  this  simple 
timing  network  runs  continuously,  the  modification  will  also 
occur  on  Saturday  and  Sunday.  With  no  weekend  shifts  in  this 
version  of  the  model,  the  Saturday  and  Sunday  node  replacements 
neither  serve  any  specific  purpose  nor  introduce  any  erroneous 
transaction  processing.  Therefore,  it  was  not  considered 
necessary  to  create  a  weekend  delay  simply  to  inhibit  that 
modification.  Subsequent  modelers  should  be  aware  that  the 
modification  is  occurring  each  day  and,  if  necessary,  revise 
the  network  segment  to  inhibit  or  provide  a  revised  modification 
procedure.  For  example,  the  Customer  Services  Saturday  and 
Sunday  shifts  are  basically  identical  to  the  weekday  second 


171 


shift.  Therefore,  the  indicated  modeler  action  would  con¬ 
sist  of  retaining  node  51  for  the  entire  weekend. 

It  should  be  apparent  that  the  weekly  master  could  easily 
be  replaced  by  a  relatively  simple  daily  master.  The  unique 
networks  accessed  from  node  266  would  have  to  be  restructured 
to  represent  a  single  day's  processing  instead  of  a  full  week 
and  the  payday  resource  impact  could  be  incorporated  without 
any  FORTRAN  program  inserts.  However,  the  weekly  master  is 
considered  an  excellent  starting  point  for  providing  a  more 
realistic  visual  display  of  daily  events  and  for  acquiring 
a  more  thorough  understanding  of  the  network  segments  through 
repetitive  referral  to  the  same  functional  areas.  In  addition, 
the  approach  used  greatly  simplifies  the  addition  of  any  daily 
uniques  or  changes  in  a  specific  day's  event  scheduling  the 
user  may  wish  to  model  and  evaluate. 

C.  PERSONNEL  RESOURCE  CONTROL 

There  are  21  distinct  resource  types  defined  in  the  model 
and  13  of  them  are  personnel  resources  that  must  be  provided 
and  removed  in  accordance  with  established  working  schedules. 

It  is  recognized  that  some  of  these  resources,  although  modeled 
as  unique,  are  actually  interchangeable.  Nevertheless,  the 
initial  model  does  not  provide  the  capability  for  dissimilar 
resources  to  process  the  same  transaction  types.  Earlier  chap¬ 
ters  did,  however,  provide  examples  of  modeling  approaches  that 
could  be  used  to  effect  such  a  processing  technique.  When  the 
model  is  validated  and  operating  satisfactorily,  embellishments 
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can  be  added  to  model  such  procedures  as  a  routine  day's  end 
backlog  evaluation  leading  to  resource  shifts  and/or  the  addi¬ 
tion  of  a  complete  shift. 

Figure  10-2  is  conceptually  very  uncomplicated  despite 
its  excessive  number  of  nodes.  Each  column  of  alter  nodes 
contains  one  node  for  each  of  the  13  personnel  resource  types. 
The  leftmost  column  of  alter  nodes  is  activated  twice  each 
day  from  the  0430  nodes  (266  is  Monday,  268  is  Tuesday,  etc.) 
on  Figure  10-1  to  reinstate  the  entire  capacity  of  each  re¬ 
source  at  0730  and  1200.  The  lower  left  partition  represents 
the  capacity  change  made  to  the  resource  type  shown  in  the 
partition  above  it.  Consequently,  it  is  apparent  that  the 
middle  column  of  alter  nodes,  which  prompt  a  capacity  change 
that  is  the  negative  of  the  left  column,  functions  to  zero 
all  resources.  This  action  is  originated  once  only  from  source 
node  265  then  once  each  day  at  1130  from  the  same  Figure  10-1 
nodes  that  trigger  the  full  capacity  increases  at  nodes  290 
through  302. 

The  first  two  alter  nodes  in  each  column  are  the  DPD  key¬ 
punch  resources,  types  3  and  4,  which  are  removed  from  the 
network  when  activity  16  has  been  completed  and  caused  the 
replacement  of  nodes  288,  304,  and  320  by  nodes  289,  305,  and 
321,  respectively.  When  node  289  is  in  the  network,  there  is 
no  further  routing  of  transactions  arriving  at  node  288;  the 
transactions  are  subjected  to  the  routing  emanating  from  the 
node  that  is  presently  in  the  circuit  and,  since  node  289  pro¬ 
vides  no  further  routing,  the  transaction  is  destroyed.  It 
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should  be  noted  that  both  304  and  320  could  have  also  been 
replaced  by  node  289  if  conserving  nodes  were  an  overriding 
factor.  In  fact,  one  node  could  have  been  used  for  the  entire 
model  to  receive  all  transactions  and  replace  all  nodes  for 
which  no  further  routing  was  desired. 

The  rightmost  column  of  alter  nodes  is  activated  from  each 
day's  1530  node  on  Figure  10-1.  This  network  segment  provides 
second  shift  resource  control  andprovides  a  description  of 
each  resource  type  for  the  convenience  of  the  reader.  Re¬ 
source  types  encountering  no  delay  at  any  point  after  node  319 
are  reduced  to  a  zero  capacity  at  1600  and  remain  unaltered 
until  0730  on  the  next  working  day.  Therefore,  resource  types 
3,  4,  8,  11,  13,  and  15  have  no  second  shift  personnel  assigned. 
This  can  be  verified  by  comparing  the  1600  resource  changes  in 
these  nodes  with  the  middle  column  resource  zeroing  capacity 
changes;  they  are  identical  so  no  resources  remain  after  1600. 

The  lack  of  a  second  shift  type  11  resource  will  prohibit  the 
packing  and  marking  of  Broadway  bulk  IPG  Is  destined  for  shipping 
until  the  next  working  day.  This  approach  was  deliberate  to 
prompt  a  comparison  of  IPG  I  statistics  collected  on  Figure  9-4. 
This  factor  is  mentioned  again  in  Chapter  11. 

Resource  types  1  and  12  encounter  an  eight  hour  delay  be¬ 
fore  arriving  at  alter  nodes  324  and  330,  respectively.  There¬ 
fore,  the  reduction  to  zero  occurs  at  2400  and  indicates  the 
second  shift  capacity  is  equal  to  the  day  shift  capacity  of  one 
Customer  Services  edit  resource  and  one  IPG  I  (OP  line)  packer/ 
marker. 
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Rsources  types  9,  10,  14,  and  16  undergo  a  1600  alteration 
that  leaves  one  of  each  resource  available  until  the  midnight 


zeroing  action  at  nodes  338,  339,  340,  and  341. 

Resource  type  2,  Customer  Services  keypunch,  is  reduced 
to  one  at  1600  at  node  325.  However,  since  the  entry  of  trans¬ 
actions  in-process  is  to  be  inhibited  during  the  release  of 
demands  in-process  from  1800  to  1830,  this  second  shift  re¬ 
source  is  removed  during  that  period  by  alter  node  335  and 
reinstated  at  1830  by  alter  node  336.  This  resource  is  also 
zeroed  at  2400  at  node  337. 

Note  that  different  second  shift  resource  schemes,  or  even 
the  addition  of  a  midnight  shift,  can  easily  be  incorporated 
into  the  Figure  10-2  logic.  A  complete  third  shift  could  be 
modeled  through  the  addition  of  a  new  alter  node  column  with 
capacity  increases  equal  to  the  desired  number  of  each  resource 
type.  The  capacity  cahnge  could  be  initiated  after  an  8.5 
hour  delay  from  the  Figure  10-1  daily  1530  nodes. 

D.  LOCAL  DELIVERY  AND  MESSENGER  SCHEDULING 

Figure  10-3  contains  three  distinct  network  segments 
referenced  in  the  discussion  of  the  weekly  master  on  Figure 
10-1.  The  upper  two  segments  are  each  initiated  by  the  arrival 
of  a  single  transaction  from  node  266,  the  Monday  0430  node, 
and  the  lower  segment  is  activated  daily  from  the  1530  nodes. 

The  lower  network  is  the  second  shift  messenger  control 
logic.  It  activates  two  messenger  runs  per  shift  to  both 
Broadway  and  National  City.  For  example,  a  transaction  arrives 
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at  node  353  from  node  267  on  Monday  at  1530.  Attribute  1  of 
the  transaction  is  set  to  zero  and  a  3.5  hour  delay  is  initiated 
when  node  353  is  released.  The  transaction  arrives  at  node 


354  at  1900  where  a  constant  1  is  added  to  the  attribute  1 
value  and  transactions  are  routed  to  nodes  83  and  72  to  initiate 
Broadway  and  National  City  messenger  runs,  respectively.  The 
complete  Broadway  run  consuming  1.9  hours  will  be  made.  Future 
model  revisions  could  provide  a  more  realistic  approach  by 
concentrating  only  on  the  transfer  of  autodin  IPG  Is  to  Customer 
Services  (Q-node  5  on  Figure  5-5)  and  IPG  I  issue  documents 
to  the  appropriate  Broadway  warehouse  area  (Q-note  78  on  Figure 
7-6) .  The  second  shift  messenger  timing  was  modeled  indepen¬ 
dent  of  the  day  shift  runs  to  facilitate  future  revisions. 
Eliminating  selected  segments  of  the  complete  messenger  run 
sequence  represents  a  greater  challenge  than  it  would  appear 
to  pose  at  first  glance.  A  user  function  that  determines 
selected  queue  contents  and  then  sends  an  identical  number  of 
matching  transactions  to  the  appropriate  match  node  represents 
one  of  the  more  logical  approaches.  If,  in  fact,  the  contents 
of  Q-node  25  are  routinely  taken  to  DPD  on  the  second  shift, 
then  no  revision  is  necessary.  This  situation  should  be  re¬ 
searched  when  the  model  is  reviewed  with  NSC  San  Diego  personnel. 
The  National  City  logic  associated  with  node  72  does  not  pro¬ 
vide  a  run  if  Q-node  70  is  empty.  Therefore,  no  modification 
of  that  logic  should  be  required. 

Returning  to  Figure  10-3,  the  initiation  of  the  1900  runs 
is  followed  by  the  conditional  branching  evaluation  at  node  355. 
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Since  attribute  1  is  one  at  1900,  the  lower  branch  back  to 
node  354,  which  contains  a  three  hour  delay,  will  be  taken. 

The  transaction  attribute  1  value  will  be  increased  to  two  at 
2200  and  a  second  messenger  run  will  begin.  At  this  time  the 
upper  branch  from  node  355  will  be  taken  and  no  further  routing 
will  be  provided  from  node  356. 

The  network  in  themiddle  of  Figure  10-3  models  the  day 
shift  messenger  service  for  the  entire  week .  A  transaction 
that  has  been  delayed  for  2.5  hours  arrives  at  node  347  at 
0700  each  Monday.  Both  attribute  1,  which  is  incremented  with 
each  day  change,  and  attribute  2,  which  is  incremented  with 
each  of  the  four  daily  runs,  are  initially  set  to  zero.  At 
node  348,  the  day  of  the  week  is  increased  by  one  and  an 
immediate  check  is  made  at  node  349  to  determine  whether  it  is 
the  sixth  day.  If  it  is,  the  transaction  is  sent  to  node  357 
and  routed  no  further;  a  run  with  attribute  1  set  at  six  would 
represent  a  Saturday  run,  which  is  not  included  in  this  version 
of  the  model.  Note  that  node  349  is  actually  extraneous.  The 
conditional  branches  could  have  been  evaluated  directly  from 
node  348  since  attribute  assignments  are  made  prior  to  evalua¬ 
ting  branching  conditions. 

If  attribute  1  is  one  through  five,  the  transaction  is 
routed  to  node  350  where  the  attribute  2  value  is  increased 
by  one  at  the  same  time  runs  are  initiated  by  the  transactions 
routed  to  nodes  72  and  83.  Therefore,  the  fourth  and  final 
daily  run  will  be  initiated  at  the  same  time  the  attribute 
2  value  becomes  four.  There  are  no  delays  encountered  between 
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node  347  and  the  arrival  of  the  first  transaction  at  node  83. 


Therefore,  the  first  Broadway  messenger  run  occurs  at  0700. 

Due  to  the  one  hour  delay  on  the  branch  from  node  350  to 

72,  the  first  National  City  run  occurs  at  0800. 

After  a  run  is  initiated  from  node  350,  attribute  4  is 
evaluated  at  node  351.  This  node  is  not  extraneous;  deter¬ 
ministic  branching  was  mandatory  at  node  350  for  messenger  run 
initiation.  If  attribute  4  is  not  equal  to  four,  the  lower 
branch  is  taken  from  node  351  and  the  incrementing  of  attri¬ 
bute  2  plus  another  messenger  run  is  accomplished  two  hours 

later.  The  last  of  the  four  daily  runs  begins  at  the  same 

time  attribute  2  is  increased  to  four,  which  occurs  at  1300 
and  leads  to  the  transaction  taking  the  upper  branch  from 
node  351  to  352.  The  process  must  begin  again  at  0700  the 
next  working  day.  Therefore,  attribute  2  is  reset  to  zero  at 
node  352  and  an  18  hour  delay  is  initiated  to  time  the  trans¬ 
action's  0700  arrival  at  node  348. 

The  network  initiates  four  messenger  runs  for  each  attribute 
1  value  from  one  to  five.  This  provides  20  runs  a  week.  It 
should  be  apparent  that  a  similar  technique  would  be  used  to 
model  five  repetitions  of  a  daily  master  if  that  approach  had 
been  used  in  place  of  the  Figure  10-1  weekly  network. 

The  upper  network  on  Figure  10-3  functions  to  provide  the 
appropriate  local  delivery  resource  (type  17  on  Monday,  18  on 
Tuesday,  etc.)  for  one  hour  commencing  at  1000  on  the  appropriate 
day.  In  this  case,  however,  the  resource  type  is  the  value 


that  is  initialized,  incremented  each  24  hours,  and  evaluated 
to  determine  the  end  of  the  week. 

The  transaction  arriving  at  node  342  from  Figure  10-1  at 
1000  on  each  Monday  is  assigned  an  attribute  1  value  of  16, 
which  is  immediately  incremented  to  17  at  node  343.  The  type 
resource  provided  by  node  344  and  retained  for  one  hour  before 
being  removed  at  node  345  is  determined  by  the  attribute  1 
value  of  the  arriving  transaction.  Therefore,  a  type  17  re¬ 
source  will  be  provided  at  1000  on  Monday,  removed  at  1100  by 
alter  node  345,  and  routed  along  the  lower  conditional  branch 
where  a  23  hour  delay  will  be  initiated.  Each  transaction 
taking  the  lower  branch  from  node  345  will  arrive  at  node  343 
at  1000  the  following  day  and  have  its  attribute  1  value  in¬ 
creased  to  equal  the  required  local  delivery  resource  type  for 
that  day.  Since  the  resource  type  has  been  available  for  the 
specified  one  hour  period  when  the  node  345  branching  evalua¬ 
tion  occurs,  an  attribute  1  value  of  21,  the  Friday  local  de¬ 
livery  resource  type,  indicates  that  the  week's  local  delivery 
routine  has  been  completed.  Therefore,  when  attribute  1  is 
equal  to  21,  the  transaction  is  routed  to  node  346  and  no 
further. 

E.  ADP  RESOURCE  CONTROL  AND  BATCH  PROCESSING 

The  upper  portion  of  Figure  10-4,  which  is  also  activated 
once  each  week  from  node  266  on  Figure  10-1,  initiates  six 
batch  processing  runs  each  work  day  and  also  provides  ADP 
resource  control  for  the  entire  week. 


Figure  10-4.  ADP  Resource 


The  modeling  technique  is  similar  to  a  combination  of  the 
two  upper  network  segments  on  Figure  10-3.  The  initial  attri¬ 
bute  1  assignment  of  zero  at  node  358  is  immediately  incre¬ 
mented  by  one  at  node  359  where  the  end-of-week  test  is  made. 
Since  attribute  1  is  equal  to  one  at  the  first  node  359  branch¬ 
ing  evaluation,  the  transaction  will  be  routed  to  node  361 
for  the  indicated  parallel  branching  to  node  369  for  batch 
processing  and  to  node  362  for  both  ADP  resource  control  and 
the  release  of  QUICK  PIC  transactions  waiting  in  Q-node  37  on 
Figure  7-5.  Node  369  of  the  batch  processing  network  initializes 
the  run  count,  attribute  2,  to  zero  at  0700  and  routes  the 
transaction  to  node  370  where  the  count  is  immediately  incre¬ 
mented  by  one  and  the  0700  batch  run  is  initiated  through  the 
routing  to  node  81  on  Figure  6-5.  The  lower  branch  from 
node  371,  with  its  accompanying  three  hour  delay,  will  be 
taken  until  the  sixth  batch  run,  which  occurs  at  2200,  is 
initiated.  Attribute  2  will  equal  six  at  that  time,  the  upper 
branch  from  node  371  will  be  taken,  and  no  further  batch  runs 
will  occur  until  the  next  transaction  is  routed  to  node  369 
from  node  361;  i.e.,  at  0700  on  the  next  working  day. 

The  11  hour  delay  on  the  lower  deterministic  branch  from 
node  361  models  the  1800  arrival  of  the  transaction  at  node 
362.  The  routing  to  node  88  on  Figure  7-5  triggers  the  re¬ 
lease  of  QUICK  PIC  transactions  in  node  37  to  either  DPD 
(mechanized)  or  Customer  Services  keypunch.  Since  there's  no 
time  expended  between  nodes  362  and  363,  a  type  6  resource  is 
also  provided  at  1800  by  alter  node  363.  It  should  be  clear 


that  node  362  is  not  actually  needed;  the  routing  to  node  88 
could  have  been  provided  with  an  additional  branch  from  node 
363.  The  type  6  resource,  the  ADP  resource  that  releases 
in-process  transactions  and  accomplishes  the  1800  special 
provisions  run,  remains  available  for  0.5  hours  until  removed 
at  node  364.  The  6.5  hour  delay  after  node  364  models  the 
elapsed  time  before  the  application  of  type  5  resources  at 
0100  to  provide  demand  processing  of  QUICK  PIC  requisitions 
waiting  in  Q-node  112  on  Figure  8-2.  The  type  5  resource  is 
removed  one-half  hour  later  at  0130.  Nodes  367  and  368  pro¬ 
vide  the  type  5  lotting  resources  for  the  two  hour  period 
between  0300  and  0500.  The  two  hour  delay  after  node  368 
completes  the  24  hour  period  between  arrivals  at  node  359. 

Therefore,  the  network  logic  beginning  at  node  361  will 
provide  five  successive  days  of  the  aforementioned  processing 
sequence  for  each  transaction  arriving  at  node  358  from  Figure 
7-1.  As  shown  on  Figure  10-4,  the  processing  period  commences 
at  0700  on  each  Monday  and  terminates  at  0700  on  the  following 
Saturday.  This  approach  is  not  completely  accurate.  Some 
of  the  late  Friday  and  early  Saturday  processing  is  actually 
conducted  late  Sunday  and  early  Monday.  For  example,  an  0100 
QUICK  PIC  run  is  conducted  early  on  Monday  rather  than  early 
on  Saturday.  Since  the  basic  model  has  no  weekend  shift,  the 
total  delay  is  not  changed.  QUICK  PIC  transactions  simply 
spend  the  weekend  in  an  issue  queue  instead  of  DPD  Q-node  112. 
However,  if  issue  resources  were  made  available  on  Saturday, 
a  model  revision  would  be  needed  to  either  delay  the  QUICK  PIC 


issues  until  Monday  or  reschedule  their  demand  processing  and 
sorting  for  early  Monday.  A  thorough  review  of  current  NSC 
San  Diego  ADP  scheduling  should  be  undertakn  during  the  model 
validation  phase.  A  Saturday  warehouse  work  force  appears 
imminent  and  is  probably  already  operational.  If  all  or  most 
of  the  issues  lotted  early  Saturday  are  issued  over  the  weekend, 
the  inclusion  of  weekend  autodin  arrivals,  which  actually  do 
occur,  limited  weekend  batch  runs,  and  an  0300  Monday  lotting 
jrogram  may  also  be  advisable  (along  with  the  aforementioned 
change  to  the  QUICK  PIC  processing  schedule) .  One  of  the  more 
convenient  features  of  modeling  with  a  weekly  master  is  the 
ease  with  which  events  unqiue  to  a  specific  day  may  be  added, 
deleted,  or  otherwise  modified  and  subsequently  displayed  with 
representative  new  or  altered  network  symbology. 

F.  AUTODIN  AND  POE  ARRIVAL  PATTERNS 

There  are  a  wide  variety  of  modeling  techniques  that  could 
be  used  to  change  the  daily  demand  interarrival  pattern  for 
both  autodin  and  POE  input.  The  autodin  interarrival  pattern 
created  at  node  1  on  Figure  6-5  is  from  the  uniform  distribution 
described  in  parameter  set  1.  The  parameters  for  this  dis¬ 
tribution  were  developed  in  Chapter  5  and  represent  the  Thursday 
autodin  uniform  interarrival  pattern.  Similarly,  the  Figure 
6-6  node  13  POE  interarrival  process,  which  is  described  in 
parameter  set  2,  represents  an  eight  hour  Thursday  demand 
pattern.  The  parameter  set  values  corresponding  to  this  dis¬ 
tribution  were  also  computed  in  Chapter  5. 
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A  distinct  parameter  set  must  be  used  to  describe  each 
day's  autodin  and  POE  interarrival  process.  In  retrospect, 
it  is  unfortunate  that  parameter  set  1  and  activity  number  1 
were  associated  with  Thursday's  demand  data.  It  would  have 
been  more  convenient  to  have  parameter  sets  1  through  5  corres¬ 
pond  to  autodin  interarrivals  for  Monday  through  Friday,  respec¬ 
tively.  POE  interarrivals  could  then  have  been  described  in 
parameter  sets  6  through  10.  Completed  figures  were  not  changed 
simply  to  provide  more  conventional  numbering  schemes.  Future 
modelers,  however,  would  be  well  advised  to  adopt  a  more  logi¬ 
cal  numbering  pattern  to  avoid  any  possible  confusion. 

The  network  symbology  in  the  bottom  half  of  Figure  10-4 
replaces  the  Figures  6-5  and  6-6  segments  preceding  nodes  2 
and  14,  respectively.  The  Appendix  E  program  listing  groups 
all  Q-GERT  cards  pertaining  to  a  particular  figure  together. 

The  cards  corresponding  to  the  Figure  10-4  sequential  delay 
network,  nodes  372  through  377  and  all  branches  leaving  these 
nodes,  are  included  with  the  coding  for  Figure  6-5.  The  nodal 
modification  network  containing  "create"  nodes  378  through 
380  plus  1  and  381  represent  the  daily  autodin  arrival  patterns 
and  are  therefore  also  listed  with  the  Figure  6-5  cards.  The 
lower  create  node  network,  which  includes  node  13  from  Figure 
6-6,  switches  the  POE  interarrival  distribution  daily  and  is 
therefore  listed  with  the  POE  categorization  cards  from  Figure 
6-6. 

The  term  create  node  refers  to  a  node  that  functions  to 
generate  transactions  until  some  programmed  event  such  as  nodal 
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modification  occurs  to  terminate  the  cycle.  By  routing  a 
duplicate  of  each  transaction  back  through  an  interarrival 
delay  to  serve  as  the  next  input,  nodes  such  as  378  will 
generate  transactions  indefinitely  unless  inhibited  in  some 
manner.  The  replacement  (modification)  of  node  378  by  node 
382  when  activity  21  has  completed  terminates  the  regenerative 
process . 

Node  372  is  a  source  node  and  will  be  released  when  the 
simulation  begins.  Unlike  source  node  265  on  Figure  10-1, 
which  routes  multiple  transactions  one  time  and  then  becomes 
inactive,  node  372  is  part  of  the  sequential  delay  network 
containing  nodes  373  through  377  and  is  released  each  Monday 
at  0430.  Therefore,  the  24  hodr  delays  designated  activities 
21  through  25  are  completed  at  0430  Tuesday  through  0430 
Saturday,  respectively.  Activity  26,  the  48  hour  delay  between 
nodes  377  and  372,  models  the  weekend  period  during  which  no 
demands  are  generated. 

Nodes  372  through  376  each  route  the  three  following  trans¬ 
actions  each  time  they  are  released:  (1)  the  activation  of 
a  24  hour  delay;  (2)  the  activation  of  an  interarrival  delay 
which,  when  completed,  will  trigger  24  consecutive  hours  of 
autodin  input;  and  (3)  the  activation  of  a  three  hour  delay 
before  initiating  the  appropriate  day's  POE  arrivals,  which 
will  terminate  after  eight  hours. 

There  are  significant  differences  between  the  autodin  and 
POE  switching  networks.  For  comparison  purposes,  consider  the 
routing  from  node  373,  which  occurs  at  0430  each  Tuesday. 
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Activity  22,  the  24  hour  delay  commences .  When  this  activity 
completes,  the  Tuesday  autodin  arrival  process  generated  by 
node  379  must  be  terminated.  The  activity  22  indicator  beside 
the  dotted  line  pointing  at  node  383  implies  that  node  383 
replaces  node  379  when  activity  22  is  completed.  Therefore, 
create  node  379  is  deactivated  at  0430  on  Wednesday.  Note 
that  node  379  will  reenter  the  network  (replace  383)  when 
activity  21  has  been  completed.  There  can  be  no  doubt  that 
activity  21  will  complete  before  the  initiating  transaction 
arrives  at  node  379.  First,  activity  21,  which  is  the  delay 
preceding  node  373,  will  be  completed  at  precisley  0430  on 
Tuesday  while  the  arrival  of  a  transaction  at  create  node  379 
from  node  373  will  be  further  delayed  by  an  amount  equal  to 
a  sample  from  the  uniform  distribution  described  in  parameter 
set  5.  Secondly,  even  if  there  were  no  uniform  delay  between 
nodes  373  and  379,  the  very  existence  of  node  373  in  the  net¬ 
work  would  ensure  that  activity  21  completed  and  node  379 
subsequently  reentered  the  network  before  a  transaction  was 
routed  from  node  373  to  379;  although  no  simulation  time  is 
expended  traversing  node  373,  the  Q-GERT  scheduling  process 
recognizes  transaction  arrival  at  a  node  and  makes  all  necessary 
network  adjustments,  including  modifications,  before  routing 
the  transaction  elsewhere.  Thus,  even  without  the  uniform  delay, 
create  node  379  would  be  in  the  network  when  the  initiating 
transaction  arrived  from  node  373. 

The  preceding  points,  which  may  appear  to  have  been  belabored, 
were  provided  to  simplify  the  discussion  of  the  contrasts  in 


188 


the  switching  network  for  POE  arrivals.  The  branch  from  node 
373  to  node  388,  Tuesday's  POE  create  node,  contains  a  three 
hour  delay  to  inhibit  the  activation  of  POE  arrivals  until 
0730.  In  this  case,  the  completion  of  activity  28  results 
in  the  simultaneous  arrival  of  a  transaction  at  node  388  and 
entry  of  that  same  node  as  the  replacement  for  node  392.  The 
question  of  which  event,  transaction  arrival  or  the  modifica¬ 
tion,  occurs  first  is  obviously  relevant.  If  the  arrival 
occurred  without  the  modification,  then  node  392  would  receive 
the  transaction  and  route  it  no  further.  Therefore,  no  POE 
arrivals  would  be  generated.  A  call  to  Pritsker  and  Associates 
yielded  an  assurance  that  the  modification  will  occur  first. 
However,  if  simulation  statistics  indicate  no  POE  input  is 
being  generated,  then  the  problem  can  be  resolved  by  inserting 
a  regular  node  in  the  network  after  the  three  hour  delay  and 
before  node  388.  A  parameter  set  6  uniform  delay  need  not 
be  included  between  the  new  node  and  node  388,  but  it  is  more 
accurate  to  have  one.  The  transaction  arriving  at  the  create 
node  not  only  starts  the  arrival  process,  but  also  represents 
the  day's  first  arrival.  Therefore,  the  first  daily  autodin 
arrival  is  always  delayed  by  an  amount  determined  by  the  appro¬ 
priate  uniform  parameter  set.  The  first  POE  arrival,  on  the 
other  hand,  always  occurs  at  0730. 

The  discussion  of  the  Tuesday  network  segment  applies  to 
every  other  day,  also.  It  should  be  apparent  that  a  Saturday 
and/or  Sunday  arrival  process  may  readily  be  inserted  by  splitting 
the  48  hour  delay  at  activity  26  and  adding  autodin  and/or  POE 


network  setments  similar  to  the  daily  symbology  shown  on 
Figure  10-4. 

As  a  final  comment  on  Figure  10-4,  activities  11  through 
15,  which  function  to  terminate  the  daily  POE  arrivals,  are 
each  11  hour  delays  from  the  Figure  10-1  weekly  master.  The 
activity  completion  time  is  1530  in  each  case  with  activity 
11  representing  Monday,  activity  12  Tuesday,  and  so  forth. 

Once  again,  each  create  node  could  have  been  replaced  by  the 
same  inhibiting/terminating  node.  Distinct  nodes  to  inhibit 
the  interarrival  process  were  used  solely  for  graphic  clarity. 

The  number  of  alternatives  to  the  selected  modeling  approach 
are  practically  unbounded.  The  Figure  10-4  model,  which  can 
be  easily  modified  due  to  being  nearly  completely  disjoint 
from  other  network  segments,  was  chosen  as  an  alternate  to  the 
replacement  of  one  create  node  by  another  through  a  process 
called  serial  nodal  modifications.  The  autodin  and  POE  arrival 
processes  could  have  been  modeled  in  a  fashion  similar  to  the 
Figure  10-5  examples  shown  below.  The  create  node  numbers 
are  identical  to  the  Figure  10-4  node  numbers,  but  the  mark 
function  and  attribute  assignments  are  omitted  and  no  further 
routing  is  shown . 

The  network  segment  presented  in  Figure  10-5  is  provided 
for  illustrative  purposes  only.  The  interarrival  parameter 
sets  are  not  shown  and  the  midweek  segment  of  the  POE  network 
was  omitted  because  it  was  simply  a  repetition  of  the  preceding 
nodes.  The  intent  here  is  to  comment  on  the  serial  nodal 
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Figure  10-5.  Serial  Nodal  Modification 
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modification  process,  not  to  provide  an  operational  alternative 
to  Figure  10-4. 

The  autodin  network  shown  on  the  left  side  of  Figure  10-5 
would  probably  function  for  one  week  if  node  372,  the  source 
node,  were  not  adapted  to  trigger  node  378  each  week  at  0430 
on  Monday.  Consider  the  replacement  of  node  378  by  379. 

When  the  24  hour  delay  that  brings  node  379  into  the  network 
i-s  complete,  there  will  probably  still  be  an  interarrival 
delay  in  process  at  node  378.  If  this  is  the  case,  the  delayed 
transaction  arriving  at  node  378  will  be  transferred  to  node 
379,  which  has  replaced  node  378,  and  initiate  the  next  day's 
arrival  pattern.  If  the  modification  and  the  completion  of 
the  node  378  interarrival  delay  occur  simultaneously,  there 
is  no  assurance  node  379  will  ever  be  triggered.  Therefore, 
specific  triggers  should  be  provided  for  each  autodin  create 
node  at  0430  on  the  appropriate  day  to  guarantee  its  activation. 
Once  the  NEW  regular  node  has  replaced  node  381  at  0430  on 
Saturday,  no  further  arrivals  will  be  generated  unless  another 
trigger  is  routed  to  node  378.  Node  378  will  replace  the  NEW 
node  at  0430  on  Monday,  but  will  not  be  activated  unless 
triggered  from  node  372  or  from  some  other  network  segment. 

Using  similar  logic,  an  external  trigger  must  be  provided 
at  each  POE  create  node.  Each  NEW  node's  time  in  the  network 
represents  the  1530  to  0730  (or  weekend)  delay  during  which 
no  POE  requisitions  arrive.  When  a  NEW  node  is  replaced  by 
a  create  node  such  as  node  388,  there  is  no  possibility  of 
any  interarrivals  in  process  serving  to  activate  the  create 
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node  just  added.  Therefore,  the  POE  switching  network  shown 
would  generate  arrivals  for  the  first  Monday  only  if  no  sub¬ 
sequent  transactions  arrived  from  node  372  or  every  Monday 
if  there  were  a  weekly  trigger  from  node  372  or  elsewhere. 

The  create  node  activation  problem  is  surmountable.  The 
approach  was  avoided  due  to  a  lack  of  understanding  of  the 
description  given  serial  modification  on  pages  178  and  179 
of  reference  (a) .  This  text  was  exceptionally  thorough  in 
most  cases.  The  examples  are  excellent  and  the  concepts  were 
generally  presented  very  clearly.  However,  more  specifics 
regarding  the  effects  of  nodal  modification,  both  serial  and 
simple  replacement,  would  have  been  helpful.  In  addition,  an 
expanded  explanation  or  definition  of  the  "node  released” 
and  "activity  completed"  criteria  may  have  eliminated  some 
confusion.  The  status  of  a  node,  released  or  not  released, 
can  be  used  as  a  branching  condition?  it  is  somewhat  unclear 
whether  a  node  released  once  can  ever  again  assume  a  not  re¬ 
leased  status.  A  similar  vagueness  surrounds  the  concept  of 
a  completed  activity?  for  example,  is  an  activity  that  is  not 
in  process  categorized  as  completed?  This  question  is  particu¬ 
larly  relevant  in  nodal  modification  modeling. 

The  most  efficient  approach  to  modeling  the  switching  or 
interarrival  patterns  would  rely  on  FORTRAN  program  inserts. 

The  create  node  interarrival  distribution  could  be  defined  as 
a  user  function,  UF,  which  could  be  programmed  to  compute  the 
day  of  the  week  from  simulation  time,  variable  TNOW,  and  select 
an  interarrival  time  using  the  parameter  set  applicable  to  that 
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day.  Therefore,  only  one  autodin  and  one  POE  create  node 
would  be  needed.  This  approach  is  made  possible  by  the 
accessibility  of  the  parameter  set  matrix  through  FORTRAN 
program  inserts.  In  accordance  with  the  objective  of  mini¬ 
mizing  FORTRAN  coding,  the  less  efficient  but  more  illustra¬ 
tive  approach  was  taken  once  again. 
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XI .  SUMMARY  AND  CONCLUSIONS 

A.  MODEL  VALIDATION 

This  section  actually  deals  wich  the  two  distinct  pro¬ 
cesses  of  verification  and  validation.  Verification  of  the 
model  consists  solely  of  ensuring  that  it  is  operational;  no 
consideration  is  given  to  how  realistically  it  portrays  the 
system  being  modeled.  The  next  few  paragraphs  cite  various 
segments  and  aspects  of  the  model  that  should  be  carefully 
reviewed  during  the  verification  process. 

The  messenger  service  described  in  great  detail  during 
the  discussion  of  Figure  6-5  should  be  closely  scrutinized. 

This  process  was  developed  to  overcome  the  absence  of  a  standard 
Q-GERT  capability  to  release  all  queued  transactions  simul¬ 
taneously.  Adding  a  branch  from  node  84  on  Figure  6-5  to  a 
statistics  node  collecting  "between"  data  should  indicate 
whether  the  modeled  technique  is  functioning  properly;  the 
time  between  arrivals  at  node  84  should  be  zero  during  the 
queue  emptying  process  and  the  first  cell  of  the  statistics 
node  histogram  can  be  defined  with  a  zero  upper  limit.  The 
output  "between"  statistics  should  then  reveal  a  preponderance 
of  zeroes  plus  values  greater  than  or  equal  to  two,  the  mini¬ 
mum  time  between  messenger  runs  (day  shift) . 

If  the  technique  does  not  work,  the  batch  node  networks 
can  be  replaced  by  a  resource  allocation  scheme  that  may 
either  be  similar  to  the  ADP  processing  technique  (capacity  of 
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1  with  an  extremely  fast  processing  time)  or  provide  a  re¬ 
source  capacity  equal  to  the  number  of  transactions  waiting 
to  be  removed.  In  the  latter  case,  the  Appendix  D  User  Func¬ 
tion  could  be  modified  to  alter  resources  after  determining 
queue  contents.  Neither  modification  may  ever  be  necessary; 
Pritsker  and  Associates  is  currently  testing  a  technique  to 
effect  the  simultaneous  movement  of  all  transactions  in  a 
Q-node  and,  if  successful,  Q-GERT  may  have  a  messenger  capa¬ 
bility  by  the  time  the  model  is  verified. 

A  caution  was  provided  regarding  the  concurrent  insertion 
of  the  Figure  10-4  POE  create  nodes  and  the  arrival  of  the 
initiating,  and  only,  transaction  at  that  same  node.  There¬ 
fore,  this  network  segment  must  also  be  carefully  reviewed 
during  verification  and,  if  necessary,  the  compensating  revi¬ 
sions  specified  in  Chapter  10  should  be  accomplished. 

The  COMMON  statement  in  the  Appendix  D  User  Function  will 
have  to  be  changed  to  provide  the  necessary  dimensioning  for 
the  1,000  node  model.  The  appropriate  COMMON  block  will  be 
apparent  when  the  1,000  node  version  is  installed.  If  it  is 
needed  any  earlier,  Pritsker  and  Associates  can  provide  it. 

SERVMART  transactions  were  originally  assigned  an  attribute 
3  value  of  8  on  Figure  6-6.  This  value  was  then  changed  to 
4.5  on  Figure  8-2  to  ensure  SERVMART  replenishments  were  lotted 
first  among  IPG  III  requisitions.  Although  the  system  will 
operate  satisfactorily  with  this  reassignment,  it  is  unnecessary 
and  subsequent  modelers  may  wish  to  simply  assign  an  original 
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attribute  3  value  of  4.5  to  SERVMARTs  on  Figure  6-6  and  delete 
the  Figure  8-2  value  assignment. 

Before  preceding  to  the  model  validation  discussion,  a 
peculiarity  in  the  use  of  Q-GERT  resources  must  be  mentioned. 
The  initial  queue  capacity  of  a  resource  al-ocation  network 
Q-node  must  be  zero.  Therefore,  a  simulation  can  not  be  com¬ 
menced  with  a  representative  backlog  loaded  in  Q-nodes  that 
are  serviced  by  network  resources.  However,  since  the  time 
to  begin  statistics  collection  is  defined  on  input  (on  the  GEN 
card) ,  the  modeler  can  and  should  delay  the  start  of  statistics 
collection  until  a  time  period  sufficient  to  stabilize  the 
system  has  passed. 

The  model's  validity  is  determined  by  the  extent  to  which 
it  duplicates  the  system  or  situation  it  was  created  to  repre¬ 
sent.  Validating  the  model  is  the  process  of  comparing  model 
output  with  observed  system  data  and  resolving  the  discrepan¬ 
cies.  The  following  paragraphs  contain  information  that  is 
relevant  to  the  validation  process.  Most  of  these  topics  were 
emphasized  as  potential  problem  areas  in  Chapters  5  through  9 
and  are  reiterated  solely  for  the  convenience  of  the  reader. 

The  development  of  the  6.2%  demand  exception  rate,  the 
lack  of  confidence  in  its  accuracy,  and  the  difficulties  asso¬ 
ciated  with  determining  a  better  estimate  were  covered  in 
Chapter  5.  It  should  prove  beneficial  to  deveease  this  rate 
in  selected  simulations  and  note  the  impact  on  the  average 
number  of  transactions  in  the  Customer  Services  keypunch  and 
edit  queues  on  Figure  7-5.  Obviously,  any  research  leading 


to  a  more  accurate  estimate  of  this  rate  would  contribute  to 
the  model's  validity. 

The  demand  data  in  Appendix  B  was  taken  from  Customer 
Services  Feeder  Reports .  Al though  this  source  permits  the 
isolation  of  distinct  categories  such  as  Special  Programs 
and  provides  a  distinction  between  POE  and  autodin  input, 
the  1144  demand  data  is  undoubtedly  more  accurate.  It  would 
appear  that  some  categorization  by  cog  for  provisions  and 
certain  bulk  material  would  be  possible.  Therefore,  con¬ 
sideration  might  be  given  to  revising  the  model  to  accommodate 
categories  that  are  identifiable  on  the  1144.  This,  of  course, 
would  be  a  long  range  goal. 

The  model  could  be  improved  immensely  with  more  realistic 
standards  for  activities  ranging  from  editing  on  Figure  7-5 
to  marking  on  9-3.  Every  constant  service  time  that  can  be 
replaced  by  a  distributional  assumption  with  a  variability 
estimate  based  on  observed  processing  times  will  contribute 
to  the  validity  of  the  model.  Packing  estimates  are  particu¬ 
larly  illustrative  of  the  necessity  for  improved  standards. 
Recently  developed  light  and  heavy  pack  standards  are  modeled 
as  identical  for  Broadway  bin  and  National  City  material  and 
higher  (more  packs  per  hour)  for  Broadway  bulk;  the  DIMES 
standards  used  in  reference  (b)  are  judged  to  be  completely 
errroneous.  Regardless  of  which  set  of  standards,  DIMES  or 
locally  developed,  are  more  accurate,  the  overriding  factor 
in  packing  is  the  tremendous  variability  in  pack  times .  Addi¬ 
tional  time  and  motion  studies  are  probably  out  of  the  question, 
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but  all  service  times  used  in  the  model  should  be  carefully 
reviewed  with  the  cognizant  functional  area  supervisors.  It 
is  possible,  or  perhaps  probable,  that  this  initial  model 
version  contains  erroneous  processing  times  due  to  the  modeler's 
misinterpretation  of  the  data  provided.  In  any  case,  all 
processing  times  should  be  confirmed  or,  if  possible,  revised 
to  include  variability  estimates.  SHORSTAMPS  program  develop¬ 
ment,  which  purports  to  determine  personnel  requirements  by 
function,  may  have  contained  an  intermediate  time-by-function 
calculation  that  is  well  documented  and  can  be  used  to  improve 
the  model  standards . 

The  uniform  interarrival  assumption  for  both  autodin  and 
POE  input  was  born  more  out  of  desperation  than  from  any 
exhaustive  research.  Time  of  arrival  data  is  not  readily 
available  and,  even  if  it  were,  it  is  hypothesized  that  the 
data  analysis  and  subsequent  goodness  of  fit  testing  would 
represent  a  major  project  in  itself.  Nevertheless,  a  more 
realistic  modeling  of  autodin  and/or  POE  interarrival  times 
might  very  well  contribute  the  most  to  model  validity. 

The  processing  of  both  provisions  and  Special  Program 
transactions  could  be  improved  by  adding  the  Customer  Ser¬ 
vices  edit  function.  These  categories  are  edited  in  their  own 
special  sections  and  a  definite  delay,  which  is  smaller  for 
provisions  documents,  is  encountered  but  accounted  for  in  the 
model.  It  has  also  been  asserted  that  a  significant  portion 
of  the  provisions  input  arrives  via  autodin  as  referrals  from 
DPSC;  it  appears  that  specified  large  local  customers  such  as 


■MU 


MCRD  (Marine  Corps  Recruiting  Depot)  submit  requisitions 
directly  to  DPSC.  The  model  could  readily  be  modified  to 
recognize  this  routing  and  its  impact  of  reducing  DPD  key¬ 
punch  provisions  workload. 

The  Special  Program  IPG  II  average  daily  input  of  107 
should  be  closely  screened.  If  it  is  erroneous,  the  model 
should  be  revised.  All  Special  Program  transactions  are 
assigned  lengthy  delays  on  Figure  7-7  to  model  their  pricing 
cycle.  Therefore,  IPG  II  requisitions  of  this  type  will  usually 
exceed  the  UMMIPS  standard  significantly.  In  recognition  of 
this  fact,  statistics  on  Special  Program  IPG  II  and  III  trans¬ 
action  processing  times  are  collected  at  nodes  256  (SPROGII) 
and  262  (SPROG3) ,  respectively,  on  Figure  9-4. 

The  calculation  of  the  National  City  heavy,  light,  and 
parcel  post  percentages  shown  on  Figure  9-3  should  be  reviewed 
with  the  packing  supervisor  and  revised  if  necessary.  Chapter 
IX. D  provided  the  rationale  for  the  computation  of  these  per¬ 
centages.  However,  the  values  do  not  appear  representative 
when  compared  to  similar  Broadway  bulk  percentages.  Therefore, 
one  or  more  of  the  assumptions  listed  in  Chapter  IX. D  are 
probably  erroneous . 

Section  IX. D  also  specified  the  QUICK  PIC  processing  routine 
as  an  analytical  starting  point.  QUICK  PICs  are  sent  to  lotted 
material  rather  than  high  priority  queues.  Therefore,  QUICK 
PIC  issue  statistics  on  Figure  9-4  should  be  reviewed  to 
determine  whether  the  processing  of  lotted  backlog  material 
is  preventing  the  actual  expeditious  issue  of  QUICK  PICs.  If 
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it  is,  QUICK  PICs  should  be  routed  to  the  IPG  I  queues  where 
their  processing  will  be  ensured. 

Finally,  it  was  noted  that  no  Broadway  Bulk  packer  (Type 
11  resource)  was  retained  on  the  second  shift,  a  factor  that 
may  erroneously  delay  IPG  I  material  destined  for  shipping. 
Node  251,  Broadway  bulk  IPH  I  interval  statistics  for  material 
shipped  (Figure  9-4),  should  be  closely  monitored  to  determine 
whether  a  second  shift  Broadway  bulk  packer/marker  should  be 
added  to  create  more  accurate  IPG  I  interval  times . 

B.  SUGGESTED  AREAS  OF  ANALYSIS 

In  the  process  of  developing  the  model  and  discussing 
current  operating  procedures  with  NSC  San  Diego  personnel, 
numerous  opportunities  for  both  model  expansion  and  the 
testing  of  alternative  modeling  techniques  became  apparent. 

The  following  model  expansions,  many  of  which  were  mentioned 
in  Chapters  5  through  10,  could  be  accomplished  in  the  future: 

.  Technical . 

.  Purchase  and  nonstandard  material  exception  processing 
by  the  demand  exception  unit. 

.  Shipping. 

.  Local  delivery  resource  control. 

.  SERVMART  Central  Receiving. 

.  Cold  storage  requisition  processing. 

.  Packing  and  preservation. 

.  Isolation  of  the  LP  and  SP  packing  lines  with  a  higher 
degree  of  consolidation  (large  customer  lines  by  definition) . 
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.  Determination  of  resource  costs  and  tradeoffs  through 
similar  resource  type  assignments  to  personnel  with  identical 
hourly  wages  and  work  capabilities. 

.  Programming  of  resource  assignments  based  on  a  backlog 
analysis  (Q-node  content  check)  conducted  in  a  disjoint  re¬ 
source  control  network. 

.  Addition  of  weekend  autodin  arrivals  and  a  limited 
Saturday  and/or  Sunday  workforce;  e.g.,  process  only  IPG  I Is 
on  the  weekend  and  measure  the  impact  of  the  response  time 
segments . 

In  addition,  after  the  model  has  been  validated  and  is 
simulating  the  current  system  satisfactorily,  the  following 
alternative  processing  techniques  could  be  modeled  and  tested: 

.  The  circumventing  of  the  packing  lines  for  approximately 
40%  of  all  binnable  material. 

.  Elimination  of  local  delivery  staging  for  local  delivery 
IPG  III  material  through  programming  thearrival  of  material 
by  conveyor  belt  for  direct  loading  on  delivery  vehicles. 

.  The  submission  of  IPG  II  transactions  to  the  same  pro¬ 
grammed  local  delivery  arrival  process.  If  statistics  nodes 
were  strategically  placed  to  measure  both  SSPT  (Storage  Site 
Processing  Time)  and  THT  (Transportation  Hold  Time) ,  it  could 
be  determined  whether  the  decrease  in  THT  more  than  compensated 
for  the  increased  SSPT. 

.  Incorporating  a  bulk  material  consolidation  factor  and 
determining  whether  time  was  actually  being  lost  due  to  the 
increased  heavy  pack  workload. 
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.  Routing  IPG  Is  through  batch  processing  and  directly 
to  the  warehouse  for  issue  rather  than  through  Customer  Ser¬ 
vices  for  remote  input. 

The  aforementioned  changes  are  only  a  few  of  the  processing 
functions  and  options  that  can  be  modeled  and  tested  once  the 
logic  of  the  basic  model  is  mastered. 

C .  CONCLUSION 

Since  there  are  no  actual  simulation  runs  being  made, 
conclusions  regarding  the  advantages  of  alternative  processing 
procedures  would  be  strictly  hypothetical.  It  was  noted,  how¬ 
ever,  that  the  IPG  II  response  time  problem  cited  in  reference 
(b)  still  exists.  Adopting  a  common  sense  approach  to  the 
analysis,  the  following  factors  contribute  significantly  to 
the  continuation  of  the  problem: 

.  Special  Program  IPG  II  material  -  if  the  Customer 
Services  Feeder  Reports  were  interpreted  correctly,  the 
lengthy  pricing  delay  experienced  by  this  significant  volume 
(107  per  day)  would  represent  a  major  detrimental  impact  on 
the  IPG  II  aggregate  response  time. 

.  Local  delivery  staging  procedures  -  prior  methods, 
which  are  to  be  changed  in  conjunction  with  the  programmed 
release  of  local  delivery  IPG  III  material,  consisted  of 
staging  IPG  IIs  and  Ills  together  by  UIC.  Therefore,  IPG 
IIs  lost  their  identity  as  higher  priority  material  after 
leaving  packing.  If  the  anticipated  staging  of  IPG  IIs 


together  and  by  delivery  zone  becomes  a  reality,  response 
time  may  improve  to  some  degree. 

.  Local  delivery  schedule  -  regardless  of  the  action 
taken  to  resolve  the  aforementioned  detrimental  factors, 
it's  apparent  that  the  response  time  on  many  IPG  II  issues 
will  continue  to  exceed  UMMIPS  standards  as  long  as  deli¬ 
veries  are  limited  to  twice  weekly  at  many  zones. 

The  model  is  completely  displayed  on  Figures  6-5,  6-6, 
7-5,  7-6,  7-7,  8-2,  9-1,  9-2,  9-3,  9-4,  10-1,  10-2,  10-3, 
and  10-4 .  The  most  efficient  method  of  reviewing  the 
chapters  6  through  10  details  is  to  make  a  separate  set  of 
the  above  figures  for  ease  of  reference.  It  is  hoped  that 
the  considerable  detail  included,  which  was  necessary  to 
describe  the  Q-GERT  concepts,  will  not  hinder  the  reviewer's 
recognition  of  the  modeling  potential  provided  by  this 
language  and  its  unique  illustrative  feature. 

The  contribution  of  employees  from  both  NSC  San  Diego 
and  Pritsker  and  Associates  toward  the  development  of  this 
model  cannot  be  minimized.  Their  cooperation,  knowledge, 
and  perhaps  most  importantly,  their  patience  were  vital 
factors  in  the  model  formulation. 
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APPENDIX  A  -  Q-GERT  Distribution  and  Function  Types  with  Required 
Parameter  Values 


Distribution 

and  Function  Types 

Parameter 

Values* 

Code 

Key 

1 

2 

3 

4 

AT 

Attribute 

- 

- 

- 

- 

BE 

Beta 

y 

a 

b 

a 

BP 

Beta  PERT 

m 

a 

b 

- 

CO 

Constant 

y 

- 

- 

- 

ER 

Erlang 

y/k 

a 

b 

k 

EX 

Exponential 

y 

a 

b 

- 

GA 

Gamma 

y 

a 

b 

a 

IN 

Incremental 

- 

- 

- 

- 

LO 

Lognormal 

y 

a 

b 

a 

NO 

Normal 

y 

a 

b 

a 

PO 

Poisson 

y-a 

a 

b 

- 

TR 

Triangular 

m 

a 

b 

- 

UF 

User  Function 

- 

- 

- 

- 

UN 

Uniform 

a 

b 

*  — ^  not  used;  y  -^mean;  a  -^standard  deviation 
m  — >  mode;  a-»  minimum  or  optimistic  time; 
b  maximum  or  pessimistic  time- 
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APPENDIX  B  -  NSC  San  Diego  Daily  Demand  Data  -  October  1979  Through  February  1980 


Monday  -  18  observations  which  include  Saturday  and  Sunday  input 


A.  ^ - Autodin  Input 


4,847  IPG  I  +  13,649  IPG  II  +  15,137  IPG  III 


33,453  TOTAL 


Max 

456 

Min 

40 

Avg 

269 

Std . 

Deviation 

118.38 

%  of 

Total 

14 . 5% 

U 

2,174 

2,001 

228 

367 

1/ 

748 

841 

465.25 

428 

40.2% 

45.3% 

1,858  Avg 
Daily  Autodin 
Input 


B. 


Hot  Line 


(Customer  Services) 


Input 


3,640  IPG  I  +  37,984  IPG  II  +  27,438  IPG  III  =  69,062 


Max 

441 

3,198 

2,904 

Min 

51 

728 

440 

3,836  Avg 

Avg 

202 

2,110 

1,524 

Daily  Hot  Line 

Std.  Deviation 

105.34 

777.6 

544.9 

Input 

%  of  Total 

5.3% 

55.0% 

39.7% 

C.4—  Provisions 

Input 

12,337  IPG  III  =  12,337  Total 


Max 

Min 

Avg 


1,558 

216 

685 


685  Avg  Daily 
Provisions  Input 


D.  ^ - -  Monday  Totals 

8,487  IPG  I  +  51,453  IPG  II  +  54,912  IPG  III  «  114,852 


Avg  471  2,858 

%  of  Total  7.4%  44.8% 


3,052  6,381  Demands 

47.8%  Per  Day 


Provisions  input  represents  10.7%  of  all  demands  and  22.5%  of  IPG  III  demand. 
Autodin  represents  29.1%  of  average  daily  demand  for  Monday. 

Autodin  represents  32.6%  of  average  daily  nonprovisions  demand. 


I^A  14  January  autodin  IPG  II  input  of  8,552  was  disregarded  and  replaced  with 
the  average  of  the  remaining  17  observations. 
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Tuesday  -  20  observations 


A.  Autodin  Input 


6, 

587  IPG  I  +  13,082 

IPG  II  + 

12,165 

IPG  III  = 

31,834  TOTAL 

Max 

622 

1,561 

1,035 

Min 

u  140 

173 

112 

1,592  Avg 

Daily  Avg 

1/  329 

655 

608 

Daily  Autodin 

Std.  Deviation 

132.05 

286.5 

235.88 

Input 

%  of  Total 

20.7% 

41.1% 

38.2% 

B.  Hot  Line  (Customer  Service)  Input 

3, 

667  IPG  I  +  37,288 

IPG  II  + 

23,480 

IPG  III  = 

64,435  TOTAL 

Max 

469 

3,476 

2,822 

Min 

44 

1,032 

197 

3,222  Avg 

Daily  Avg 

183 

1,865 

1,174 

Daily  Hot  Line 

Std.  Deviation 

95.5 

764.7 

637.16 

Input 

%  of  Total 

5.7% 

57.9% 

36.4% 

C.  Provisions  Input 

9,979 

IPG  III  ® 

9,979  TOTAL 

Max 

1,457 

525  Avg 

Min 

216 

Daily  Provisions 

Daily  Avg 

525 

Input 

D.  Tuesday  Totals 

10 

,254  IPG  I  +  50,370 

IPG  II  + 

45,624 

■  IPG  III  < 

•  106,248 

Daily  Avg 

526 

2,519 

2,281 

5,326  Demands 

%  of  Total 

9.65% 

47.4  % 

42.95% 

Per  Day 

Provisions  input 

represents  9.4%  of 

all  demands  and 

1  21.9%  of 

IPG  III  demand. 

Autodin  represents  30.0%  of  average  daily  demand  for  Tuesday. 
Autodin  represents  33.1%  of  average  daily  nonprovisions  demand. 


^  A  zero  ("0")  IPG  I  autodin  input  was  replaced  by  the  average  of  the  19 
other  values. 
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Wednesday  -  21  observations 


A.  Autodin  Input 


6,322 

IPG  I  + 

13,178 

IPG  II  + 

16,551 

IPG  III  = 

36,051 

TOTAL 

Max 

826 

1,376 

1,939 

Min 

25 

159 

268 

Daily  Avg 

301 

628 

788 

1,717 

Avg 

Std.  Deviation 

221.4 

284.2 

431.9 

Daily 

Autodin 

%  of  Total 

17.5% 

36 . 5% 

46.0% 

Input 

B.  Hot  Line  (Customer  Service)  Input 

3,215 

IPG  I  + 

37,902 

IPG  II  + 

27,331 

IPG  III  = 

68,448 

TOTAL 

Max 

392 

3,342 

2,397 

Min 

56 

282 

269 

3,259 

Avg 

Daily  Avg 

153 

1,805 

1,301 

Daily 

Hot  Line 

Std.  Deviation 

85.8 

728.3 

536.1 

Input 

%  of  Total 

4.7% 

55.3% 

40.0% 

C.  Provisions  Input 

7,965 

IPG  III  = 

:  7,965 

TOTAL 

Max 

Min 

Daily  Avg 


944  379  Avg 

132  Daily  Provisions 

379  Input 


D.  Wednesday  Totals 

9,537  IPG  I  +  51,080  IPG  II  +  51,847  IPG  III 


Daily  Avg 
%  of  Total 


454 

8.5% 


2,432 

45.4% 


2,469 

46.1% 


112,464 

5,355  Demands 
Per  Day 


Provisions  input  represents  7.1%  of  all  demands  and  15.4%  of  IPG  III  demand. 
Autodin  represents  32.0%  of  average  daily  demand  for  Wednesday. 

Autodin  represents  34.5%  of  average  daily  nonprovisions  demand. 
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Thursday  -  20  observations 


A.  Autodin  Input 


6,134  IPG  I  +  15,650  IPG  II  +  14,794  IPG  III  *  36,578  TOTAL 


Max 

505 

2,009 

1,176 

Min 

60 

335 

395 

1,829  Avg 

Daily  Avg 

307 

783 

740 

Daily  Autodin 

Std.  Deviation  120.62  445.37  243.27  Input 

%  of  Total  16.8%  42.8%  40.4% 

B.  Hot  Line  (Customer  Service)  Input 


3,051  IPG  I  +  31,377  IPG  II  +  16,590  IPG  III  =  51,018  TOTAL 


Max 

303 

3,834 

2,906 

Min 

62 

769 

201 

2,551  Avg 

Daily  Avg 

153 

1,569 

830 

Daily  Hot  Line 

Std.  Deviation 

76.47 

763.77 

339.9 

Input 

%  of  Total 

6.0% 

61.5% 

32.5% 

C.  Provisions  Input 

10,987  IPG  III 

*  10,987  TOTAL 

Max 

1,069 

550  Avg 

Min 

216 

Daily  Provisions 

Daily  Avg 

550 

Input 

D.  Thursday  Totals 

9,185  IPG  I  +  47,027  IPG  II  +  42,371  IPG  III  =  98,583 

Daily  Avg  459  2,351  2,119  4,929  Demands 

%  of  Total  9.3%  47.7%  43.0%  Per  Day 


Provisions  input  represents  11.1%  of  all  demands  and  25.9%  of  IPG  III  demands 
Autodin  represents  37.1%  of  average  daily  demand  for  Thursday. 

Autodin  represents  41.8%  of  average  daily  nonprovisions  demand. 
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Friday  -  22  Observations 
A.  Autodin  Input 


8,215 

IPG  I  +  14,568  IPG 

II  +  16,051 

IPG 

III  -  38, 

834  Total 

Max 

741 

1,331 

1,227 

Min 

24 

320 

238 

Daily  Avg 

373 

662 

730 

1,765  Avg 

Daily  Autodin 

Std.  Deviation 

189.1 

251.3 

266.1 

Input 

%  of  Total 

21.2% 

37.5  % 

41.3% 

B.  Hot  Line  (Customer  Services) 

Input 

3,978 

IPG  I  +  34,315  IPG 

II  +  23,021 

IPG 

III  =  61, 

314  Total 

Max 

352 

2,662 

2,911 

Min 

45 

661 

225 

Daily  Avg 

181 

1,560 

1,046 

2,787  Avg 

Daily  Hot  Line 

Std.  Deviation 

.  75.75 

556.4 

690.9 

Input 

%  of  Total 

6.5% 

56.0% 

37.5% 

C.  Provisions 

Input 

12,862  IPG 

III 

*  12,862 

Total 

Max 

1,687 

Min 

216 

585  Avg 

Daily  Provisions 

Daily  Avg 

585 

Input 

D.  Friday  Totals 

12,193 

IPG  I  +  48,883  IPG 

II  +  51,934 

IPG 

III  =  113,010 

Daily  Avg 

554 

2,222 

2,360 

5,136  Demands 

%  of  Total 

10.8% 

43.3% 

45.9% 

Per  Day 

Provisions  input  represents  11.4% 

of  all  demands 

and  24.8% 

of  IPG  III  demands 

Autodin  represents  34.4%  of  average  daily  demand  for  Friday. 
Autodin  represents  38.8%  of  average  daily  nonprovisions  demand. 
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APPENDIX  D  -  Model  FORTRAN  User  Functions 


FUNCTION  UF  (TFN) 

l J  COMMON/QVAR/NDE,  NFTBU  (100),  NREL  (100),  NRELP  (100),  NP.EL2  (100), 

INRUN,  NRUNS,  NTC  (100),  PARAM  (100,4),  TBEG,  TKNOW 

UF  =  -NREL  (INF) 

RETURN 

END 

The  statement  UF  =  -  NREL (INF)  indicates  that  the  value  returned  to  the  model 
is  the  negative  of  the  number  of  transactions  in  0-node  INF.  Therefore,  if 
UF  43  were  used  in  the  network  logic,  the  value  returned  would  be  minus  the 
number  of  transactions  in  Q-node  43,  the  Customer  Services  keypunch  aueue  on 
Figure  6-5. 


ij  The  COMMON  statement  applies  for  the  100  node  model  as  indicated  by  the 
dimensioning  of  the  various  matrices.  When  the  1,000  node  model  is  oper¬ 
ational,  this  COMMON  statement  will  have  to  be  revised  accordingly. 


LIST  OF  REFERENCES 


a.  Pritsker,  A.  Alan  B. ,  Modeling  and  Analysis  Using  Q-GERT 
Networks ,  Second  Edition  1979. 

b.  Lynch,  M.  G.,  and  Ulrich,  C.  H. ,  Requisition  Throughput 
Time  Simulation  at  Naval  Supply  Center  San  Diego,  U.S. 
Naval  Postgraduate  School  Thesis,  March  1973. 

c.  NSC,  San  Diego,  Defense  Integrated  Management  Engineering 
Systems  (DIMES)  Methods  Engineering  Survey  Handbooks, 
1968-1970. 

d.  OPNAVINST  4614. IE,  Uniform  Material  Movement  and  Issue 
Priority  System  (UMMIPS) ,  29  July  1975. 

e.  NSC,  San  Diego,  Customer  Services  Monthly  Input  Feeder 
Reports,  October  1979  -  February  1980. 


213 


r 


INITIAL  DISTRIBUTION  LIST 


No.  Copies 

1.  Defense  Technical  Information  Center  2 

Cameron  Station 

Alexandria,  Virginia  22314 

2.  Library,  Code  0142  2 

Naval  Postgraduate  School 

Monterey,  California  93940 

3.  Department  Chairman,  Code  55  1 

Department  of  Operations  Research 

Naval  Postgraduate  School 
Monterey,  California  93940 

4.  Associate  Professor  F.  R.  Richards,  Code  55Rh  1 
Department  of  Operations  Research 

Naval  Postgraduate  School 
Monterey,  California  93940 

5.  U.S.  Naval  Supply  Center  2 

San  Diego,  California  92132 

Attn:  Codes  100,  300B 

6.  Pritsker  and  Associates  2 

P.0.  Box  2413 

West  Lafayette,  Indiana  47906 
Attn:  J.  Sabuda 

7.  Fleet  Material  Support  Office  2 

Mechanicsburg,  Pennsylvania  17055 

Attn:  Code  933 

8.  LCDR  Bruce  R.  Faurie  4 

Box  5,  Code  SA 

U.S.  Naval  Support  Activity 
FPO,  New  York,  New  York  09521 


